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1 Scope 

IP Multimedia (IM) Core Network (CN) subsystem inter-UE transfer (lUT) provides the capability of continuing 
ongoing communication sessions with multiple media across different user equipments (UEs) under the control of the 
same or different subscribers, and as part of Service Continuity (SC). 

The present document provides the protocol details for enabling IMS inter-UE transfer based on the Session Initiation 
protocol (SIP) and the Session Description Protocol (SDP). 

The present document is apphcable to User Equipment (UEs) and Apphcation Servers (AS). 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22. 1 73 : "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services; Stage 1". 

[3] 3GPP TS 23.003: "Numbering, addressing and identification". 

[4] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[5] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[6] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[7] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[8] 3GPP TS 24.238: "Session Initiation Protocol (SIP) based user configuration; Stage 3". 

[9] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem Centrahzed Services (ICS); 

Stage 3". 

L 1 OJ 3GPP TS 24.604: "Communication Diversion (CDIV) using IP Multimedia (IM)Core Network 

(CN) subsystem; Protocol specification". 

[I I] 3GPP TS 24.605: "Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem; 
Protocol specification". 

[12] 3GPP TS 24.606: "Message Waiting Indication (MWI) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 

[13] 3GPP TS 24.607: "Originating Identification Presentation (OIP) and Originating Identification 

Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
Specification". 
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[14] 3GPP TS 24.608: "Terminating Identification Presentation (TIP) and Terminating Identification 

Restriction (TIR) using IP Multimedia (IM)Core Network (CN) subsystem; Protocol 
Specification". 

[15] 3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 

[16] 3GPP TS 24. 611: "Anonymous Communication Rejection (ACR) and Communication Barring 

(CB); using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification". 

[17] 3GPP TS 24.629: "Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core 

Network (CN) subsystem; Protocol specification". 

[18] 3GPP TS 24.239: "Flexible Alerting (FA) using IP Multimedia (IM) Core Network (CN) 

subsystem; Protocol specification". 

[19J 3GPP TS 24.259: "Personal Network Management (PNM); Stage 3". 

[20] 3GPP TS 24.615: "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) 

subsystem; Protocol Specification". 

[21] 3GPP TS 24.616: "Malicious Conrnunication Identification (MCID) using IP Multimedia (IM) 

Core Network (CN) subsystem; Protocol Specification". 

[22] 3GPP TS 24.642: "Completion of Communications to Busy Subscriber (CCBS) and Completion of 

Communications by No Reply (CCNR) using IP Multimedia (IM)Core Network (CN) subsystem; 
Protocol Specification". 

[23] 3GPP TS 24.647: "Advice Of Charge (AOC) using IP Multimedia (IM)Core Network (CN) 

subsystem; Protocol Specification". 

[24] 3GPP TS 24.654: "Closed User Group (CUG) using IP Multimedia (IM) Core Network (CN) 

subsystem, Protocol Specification". 

[25] 3GPP TS 29.292: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and MSC Server for IMS CentraUzed Services (ICS)". 

[26] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; SignalUng flows and message 

contents". 

[27] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[28] IETF RFC 792 (September 1981): "INTERNET CONTROL MESSAGE PROTOCOL". 

[29] IETF RFC 3023: "XML Media Types". 

[30] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[31] IETF RFC 3264 (June 2002): "An Offer/Answer Model with the Session Description Protocol 

(SDP)". 

[32] IETF RFC 3515: "The Session Initiation Protocol (SIP) Refer Metiiod". 

[33] IETF RFC 3556 (July 2003): "Session Description Protocol (SDP) Bandwidtii Modifier" . 

[34] IETF RFC 3840 (August 2004): "Indicating User Agent Capabilities in the Session Initiation 

Protocol (SIP)". 

[35] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header". 

[36] IETF RFC 3892 (September 2004) "The Session Initiation Protocol (SIP) Referred-By 

Mechanism" . 

[37] IETF RFC 4028: "Session Timers in the Session Initiation Protocol (SIP)" . 

[38] IETF RFC 4235 (November 2005): "An INVITE-Initiated Dialog Event Package for die Session 

Initiation Protocol (SIP)". 
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3 Definitions and abbreviations 
3.1 Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPP TR 21.905 [1]. 

Controller capable UE: A UE that is capable of becoming a controller UE. 

Inter UE Transfer SCC AS URI: A SIP URI which is a public service identity hosted by SCC AS and which is used 

in inter UE transfer procedures. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [4] apply: 

Remote Leg 
Collaborative session 
ControUee UE 
ControUer UE 
Inter-UE transfer 
Service Continutiy 

For the purposes of the present document, the following terms and definitions given in IETF RFC 4353 [39] apply: 

Conference 
Conference URI 
Focus 
Participant 

For the purposes of the present document, the following terms and definitions given in IETF RFC 3264 [31] apply: 
Directionality 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

SC Service Continuity 

SCC Service Centralization and Continuity 

STI Session Transfer Identifier 

XCAP Extensible Markup Language (XML) Access Configuration Protocol 
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4 Overview of IP Multimedia (IM) Core Network (CN) 
subsystem inter-UE transfer 

4.1 General 

Inter-UE transfer provides the capability of transferring the communication sessions with multiple media across 
different UEs and is part of Service Continuity (SC) as described in 3GPP TS 23.237 [4]. 

Inter-UE transfer does not apply to emergency calls as described in 3GPP TS 24.229 [7]. 

Inter-UE transfer is an optional part of SC. 

The following procedures are provided within this document: 

procedures for UE discovery for inter-UE transfer are specified in clause 9; 

procedures for inter-UE transfer without establishment of collaborative session are specified in clause 10; 

- procedures for collaborative session estabhshment for inter-UE transfer are specified in clause 1 1 ; 

NOTE: The procedures in clause 1 1 are related to scenarios in which the collaborative session is set up by the 
controller UE when a end-to-end session already has been established with the remote UE. 

procedures for media transfer within collaborative session for inter-UE transfer are specified in clause 12; 

- procedures for release of collaborative session for inter-UE transfer in clause 13; 

- procedures for addition and deletion of media with collaborative session for inter-UE transfer in clause 14; 

- procedures for session discover in clause 15; 

- procedures for collaborative sessions of participants of different subscriptions are specified in clause 16; 

procedures for estabhshment of collaborative sessions during session setup are specified in clause 17; 

NOTE: The procedures in clause 17 are related to scenarios in which the collaborative session and the session 
towards the remote UE are set up in parallel. 

- procedures for assignment and transfer of control of a collaborative session are specified in clause 18; 

- procedures for media flow transfer within a collaborative session are specified in clause 19; 
procedures for session replication / media replication performed by the SCC AS are specified in clause 20; 
procedures for session replication / media replication performed by the remote UE are specified in clause 19; 

- procedures for collaborative session handling upon loss of collaborative session are specified in clause 22; and 

- procedures for collaborative session media modification are specified in clause 23; and 

- procedures for service continuity and MMTEL interactions are specified in clause 24. 
Inter-UE transfer procedures are not limited by amount of established sessions. 

4.2 Underlying network capabilities 

Inter-UE transfer assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 
3GPPTS 24.229 [7]. 
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4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE for inter-UE transfer will be configured with an Inter UE Transfer 
sec AS URI. The Inter UE Transfer SCC AS URI is used in the inter UE transfer procedures. 



5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the inter-UE transfer roles described in the stage 2 architecture 
document (see 3GPP TS 23.237 [4]). 

5.2 User Equipment (UE) 

If the SC UE supports the Controller UE procedures for lUT transfer then the SC UE may include the g.3gpp.iut- 
controUer media feature tag as described in annex B in the Contact header of SIP requests and SIP responses. 

To be compliant with inter-UE transfer in this document, a UE shall implement the role of an SC UE: 

- by following the procedures specified in 3GPP TS 24.229 [7] for registration of the UE in the IM CN subsystem; 
and 

- dependent on the desired functionality, one or more of the procedures according to subclause 9.2, subclause 10.2, 
subclause 11.2, subclause 12.2, subclause 13.2, subclause 14.2, subclause 15.2, subclause 16.2, subclause 17.2, 
subclause 18.2, subclause 19.2, subclause 20.2, subclause 21.2, subclause 22.2, subclause 23.2 and 

subclause 24.2. 

NOTE: In the inter-UE transfer, a session can be collaborative session where there are one controller UE and 

severeal controUee UEs. The controUee UE can be a legacy UE and does not have be compliant with the 
above subclauses. 

5.3 Application Server (AS) 

To be compliant with inter-UE transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 9.3, subclause 10.3, subclause 11.3, subclause 12.3, subclause 13.3, subclause 14.3, subclause 15.3, 
subclause 16.3, subclause 17.3, subclause 18.3, subclause 19.3, subclause 20.3, subclause 21.3, subclause 22.3, 
subclause 23.3 and subclause 24.3. 



6 Roles for registration in the IM CN subsystenn for 
service continuity 

6.1 SCUE 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [7] for registration of the UE in the IM CN 
subsystem. 

If the SC UE supports the Controller UE procedures for lUT transfer then the SC UE shall include the g.3gpp.iut- 
controUer media feature tag as described in annex B in the Contact header field of the SIP REGISTER request. 
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6.2 sec AS 

The sec AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third- 
party SIP REGISTER request) as specified in 3GPP TS 24.229 [7]; 

b) any received reg event package as specified in 3GPP TS 24.229 [7]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [26] and 3GPP TS 29.329 |27|. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabiUties supported by the user registered UE(s), including the used IP-CAN(s). 

7 Roles for General Capabilities 

7.1 Introduction 

This clause describes the general roles for each functional entity as specified. 

7.2 UE roles 

Configuration of user preference criteria for routing incoming session requests to a controller capable UE is specified in 
subclause 7.3.1 and for controller loss preference is specified in subclause 7.3.2. 

7.3 AS roles 

7.3.1 Configuration of user preference criteria for routing incoming session 
requests to a controller capable UE 

Configuration of user preference criteria by the user should: 

- take place over the Ut reference point using XCAP as enabling protocol; or 

- use SIP based user configuration as described in 3GPP TS 24.238 [8]; 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 
operator are outside the scope of the present document, but are not precluded. 

The structure of the XML document and the schema for the user preference criteria is defined in annex C.3 

7.3.2 Configuration of controller loss preference 

Configuration of controller loss preferences by the user should: 

- take place over the Ut reference point using XCAP as enabling protocol; or 

- use SIP based user configuration as described in 3GPP TS 24.238 [8]; 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 
operator are outside the scope of the present document, but are not precluded. 

The structure of the XML document and the schema for configuring the hst of preferred UEs that are used in the case of 
controller loss is defined in annex C.3. 
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8 Roles for call termination for inter UE transfer 

8.1 Introduction 

This clause specifies the procedures for call termination for inter UE transfer. Procedures are specified for the SC UE 
and the SCC AS. 

8.2 SC UE 

There are no additional procedures for the SC UE over those specified in 3GPP TS 24.229 [7]. 

8.3 SCC AS 

8.3.1 Routing incoming session requests to a controller capable UE 

When the SCC AS receives an incoming initial session establishment request it checks the request against the following 
stored user preference criteria to see if collaborative sessions are enabled for this session: 

- URI in the P-Asserted-Identity header field; 

- URI in the Request-URI; 

any ICSl value in the P-Asserted-Service header field; and 

- media types in the SDP offer. 

If the stored user preference criteria indicates that collaborative sessions are enabled for this session then the SCC AS 
shall include the media feature tag g.Sgpp.iut-controUer along with the explicit parameter in an Accept-Contact header 
field in the request before forwarding. 



9 Roles for UE discovery for inter-UE transfer 

9.1 Introduction 

This clause specifies the target UE discovery procedures for UEs that are candidate UEs for inter UE transfer. The list 
of candidate UEs is a contact list such as name of the UE, which is represented in SIP through the use of SIP contact or 
the instance-id. The subscription of candidate UEs may be configured such that the private user identities associated 
with the UEs involved in inter UE transfer share the same set of implicitly registered public user identities. 

9.2 SC UE 

The target UE discovery procedures include the registration status (active, inactive), and the UE capabilities (e.g. 
support of audio/video formats etc.). 

In order to determine a list of UEs sharing the same set of implicitly registered public user identities and their capability 
information, the SC UE subscribes to the reg-event package as described in 3GPP TS 24.229 [7] in subclause 5.1.1.3. 

NOTE 1 : In order to allow inter UE transfer to UEs belonging to the same user subscription but belonging to a 
different set of implicitly registered public user identities, a user can have a static list of UEs that is 
manually administered by the user and stored locally in the user's device (e.g. phone book). Having a 
static list is an implementation in the UE and has no impact on the standards. 
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NOTE 2: If the UE is not part of the same set of implicitly registered public user identities as the SC UE, or if the 



SC UE was unable to obtain the capability information of the UE through the use of reg-event package, 
the SC UE can send a SIP OPTIONS request to the UE to attempt to retrieve capability information. In 
order to avoid a lot of transactions, a SIP OPTIONS request is generated based on an action initiated by 
the user (e.g. after the user has finished adding a new UE in the static list, or the user explicitly asks for 
getting UE capability information). 



The information of UEs that belong to the same subscription is required at the SCC AS for the purpose of authorizing 
that the requested inter UE transfer to the UE is allowed, i.e. to prevent the SC UE from performing Inter UE Transfer 
to a UE with a different user subscription. 

The SCC AS obtains all the public user identities associated with the user's subscription from the Sh interface as 
specified in 3GPP TS 29.328 [26] and 3GPP TS 29.329 [27]. 

NOTE 1: Getting the public user identities over the Sh interface allows the SCC AS to receive information of UEs 



sharing the same set of implicitly registered public user identities and information of UEs within the same 
user subscription that are not in the same set of implicitly registered pubhc user identities. This is needed 
to authorize the static list of UEs that is manually administered by the user and stored locally in the user's 
device. 



The SCC AS can obtain the registration information (e.g. GRUU) by the following methods: 

1. using the 3rd-party SIP REGISTER request as described in 3GPP TS 24.229 [7] in subclause 5.4.1.7; or 

2. the SCC AS subscribes to the reg-event package as described in 3GPP TS 24.229 [7] in subclause 5.4.2.1.1. 

NOTE 2: The SCC AS needs to know the public user identity for the authorization of the SIP REFER request for 
inter UE transfer. To get the public user identity from the public GRUU, the SCC AS can simply remove 
the "gr" parameter from the public GRUU. Using the 3rd-party registration or subscribing to the reg-event 



package allows the SCC AS to find the temporary GRUU of the UE and to correlate the GRUU with the 
public user identities. After correlation, the SCC AS would make a list of GRUUs that are associated with 
the same subscription and/or with the same set of imphcitly registered public user identities. 



1 Roles for inter-UE transfer without establishment of 
collaborative session 

10.1 Introduction 



This clause specifies the procedures for transferring all media of an existing session from one UE to another UE of the 
same subscriber. Procedures are specified for the SC UE and the SCC AS. 



10.2 SCUE 

1 0.2.1 SC UE participating in tlie session to be transferred 

1 0.2.1 .1 Transferor SO UE in services defining only originating session set up in UE 



In order to transfer all media of an existing session from this SC UE to another UE that shares the same user 
subscription, the SC UE shall send a SIP REFER request as specified in IETF RFC 35 15 [32J and in accordance with 
UE procedures specified in 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER request as follows: 

1 . the Request-URI set to the URI of the UE where the session is to be transferred to; 

NOTE: The URI of the UE needs to be a GRUU if several UEs share the same pubhc user identity. 



9.3 



SCC AS 
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2. the Refer-To header field set to the Inter UE Transfer SCC AS URI and extended with the following URI header 

fields: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [35], containing the dialog identifier 
of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog 
identifier of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "tdialog"; and 

C. if the session is established using an IMS communication service that requires the use of an IMS 
communication service identifier: 

a. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS 
communication service identifier of the existing session; and 

b. the P-Preferred-Service header field set to the IMS communication service identifier of the existing 
session; and 

3. the Contact header field: including a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [7]. 

If the SC UE receives any SIP 4xx, SIP 5xx, or SIP 6xx response to the SIP REFER request or if the SC UE receives a 
SIP NOTIFY request containing a message/sipfiag body of any SIP 4xx, SIP 5xx or SIP 6xx response, then the inter UE 
transfer has not completed successfully. 

1 0.2.2 SC UE not participating in tine session to be transferred 

10.2.2.1 Transferee SC UE in services defining only originating session set up in UE 

When sending a SIP INVITE request upon SIP REFER request reception in accordance with UE procedures specified in 
3GPP TS 24.229 [7] and IETF RFC 3515 [32], the SC UE shall populate the SIP INVITE request with header fields 
which were included as URI header fields in the URI in the Refer-To header field of the received SIP REFER request. 

1 0.2.2.2 Inter UE transfer triggered by SC UE not participating in the session 

In order to transfer all media streams of an existing session of another UE to the SC UE, the SC UE shall send a SIP 
INVITE request as specified in 3GPP TS 24.229 [7]. The SC UE shall populate the SIP INVITE request as follows: 

1 . the Request-URI set to the Inter UE Transfer SCC AS URI; 

2. the Replaces header field containing the dialog identifier of the session to be transferred; and 

3 . the Require header field containing the option tag value "replaces" . 

10.3 SCC AS 

1 0.3.1 Distinction of requests sent to tlie SCC AS 

The SCC AS needs to distinguish between the following SIP requests to provide specific functionaUty relating to inter 

UE transfer: 

1. SIP INVITE request routed to the SCC AS upon originating or terminating filter criteria containing the Inter UE 
Transfer SCC AS URI in the Request-URI and a STI belonging to the same user subscription in: 

A. the Target-Dialog header field; or 
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B. in the Replaces header field 

with at least one offered media type used in session by a UE other than the UE identified by the Contact header 
field value. Then in the procedures below, such a request is known as "SIP INVITE request due to inter UE 
transfer". 

2. SIP REFER request routed to the SCC AS due to the originating filter criteria where: 

A. the GRUU in the Contact header field identifies a UE of the user identified in P-Asserted-Identity header 
field; 

B. the GRUU in the Contact header field identifies a UE of the same user subscription as the SIP URI in the 
Request-URI; 

C. the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field; 
belongs to a session of the UE identified by the GRUU in the Contact header field; and 

D. the Refer-To header field contains the Inter UE Transfer SCC AS URI either without method parameter or 
with method parameter set to "INVITE". 

Then in the procedures below, such a request is known as "SIP REFER request due to inter UE transfer". 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [7]. 

1 0.3.2 Inter UE transfer request authorization in services defining only 
originating session set up in UE 

Upon receiving a SIP REFER requests due to inter UE transfer, the SCC AS shall: 

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if: 

A. the media streams of the session, one leg of which is identified by the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field; 
are dehvered to two or more UEs of the same user subscription; or 

B. at least one media stream of the session identified by the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field 

is dehvered to a UE other than the UE identified by the GRUU in the Contact header field; 

2. insert a Record-Route header field with SCC AS own address; and 

3. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [7]. 

The SCC AS shall forward the SIP response to the SIP REFER request, the associated SIP NOTIFY request, and the 
SIP response to the NOTIFY request conformant with 3GPP TS 24.229 [7]. 

1 0.3.3 SCC AS procedures for inter UE transfer 

Upon receiving a SIP INVITE request due to inter UE transfer, the SCC AS shall: 
1. if: 
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A. the sec AS is not aware of a subscription created by a SIP REFER request with the dialog identifiers: 

a. in the Replaces header field of the received SIP INVITE request and in the Replaces URI header field of 
the URI in the Refer-To header field of the SIP REFER request are equal; or 

b. in the Target-Dialog header field of the received SIP INVITE request and in the Target-Dialog URI 
header field of the URI in the Refer-To header field of the SIP REFER request are equal; and 

B. the sec AS does not authorize the request on behalf of the served user participating in the session indicated 
in the Replaces header field; 

then reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; 

2. associate the received SIP INVITE request with an ongoing SIP dialog by matching the dialog identifier in the 
Replaces header field or the Target-Dialog header field. By an ongoing SIP dialog, it is meant a dialog for which 
a SIP 2xx response to the initial SIP INVITE request has been sent or received; 

3. if a dialog identifier is not included in either in the Replaces header field or in the Target-Dialog header field or 
if the included dialog identifier does not identify an existing ongoing dialog, send a SIP 480 (Temporarily 
Unavailable) response to reject the SIP INVITE request and not processes the remaining steps; 

4. identify the Source Access Leg by the dialog identifier present in the Replaces or the Target-Dialog header field 
of the SIP INVITE request; 

5. if a media type used in the Source Access Leg session is not offered in the SDP offer of the SIP INVITE request 
then reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; 

6. if the SIP INVITE request contains a Replaces header field: 

A. follow the procedures defined in IETF RFC 3891 [35] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [7]; and 

7. send a SIP re-INVITE request towards the remote UE using the existing estabhshed dialog. The SCC AS shall 
populate the SIP re-INVITE request as follows: 

A. include a new SDP offer including the media characteristics as received in the SIP INVITE request, by 
following the rules of the 3GPP TS 24.229 [7]; and 

B. set the Contact header field to the Contact header field value recieved in the SIP INVITE request. 

Upon receiving the SIP ACK request originated from the SC UE, the SCC AS shall initiate release of the Source Access 
Leg by sending a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [7]. 



1 1 Roles for collaborative session establishment for 
inter-UE transfer 

11.1 introduction 

This clause specifies the roles of controller UE, controUee UE and the SCC AS when controller UE transfers media 
used in an existing session to a controUee UE or adds a new media to an existing session on the controUee UE. 
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11.2 SCUE 

1 1 .2.1 SC UE procedures for collaborative session establishment by 
transferring media used in an existing session 

1 1 .2.1 .1 Controller UE procedures 

To establish a collaborative session by transferring one or more media components, the controller UE shall send a SIP 
REFER request outside the existing dialog as specified in IETF RFC 3515 [32] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 

same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) Unes in the session set as follows: 

- media lines that are not being transferred with the port number set to zero; 

- media line(s) that are to be transferred containing the port number for the corresponding media types 
received in the media line of the SDP received during the last successful SDP offer/answer exchange; and 

c) if the controller UE also wishes to transfer control of the collaborative session to the controllee UE then the 
SIP URI additionally containing the XML body specified for the Refer-To URI in subclause 18.2.1; 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session 

5) the Contact header field containing: 

the g.3gpp.iut-controller media feature tag as described in annex B; and 

- the g.3gpp current-iut-controUer media feature tag as described in annex C set to "passive" if the controller 
UE does not wish to be the controller of the collaborative session; and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [7] and IETF RFC 3515 [32]. The controller UE shall save the media information (i.e. 
media type(s) and port number(s)) related to the transferred media component(s) received in the sipfrag body of the SIP 
NOTIFY requests in order to perform further inter-UE transfer operations on the controllee UE. When the controller UE 
receives a SIP re-INVITE request from the SCC AS to update the status of the transferred media component after a 
successful transfer, the controller UE shall foUow the procedures described in 3GPP TS 24.229 [7], including in the 
Contact header field of the SIP 200 (OK) response the g.3gpp.iut-controUer media feature tag as described in annex B. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session with 
media components prior to the failed transfer attempt. 

1 1 .2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session establishment by transferring media, 
besides the procedures described in 3GPP TS 24.229 [7]. 
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1 1 .2.2 SC UE procedures for collaborative session establishment with new 
media 

1 1 .2.2.1 Controller UE procedures 

The controller UE may establish a collaborative session with a new media at anytime while it has an ongoing IMS 
estabUshed session according to 3GPP TS 24.229 [7] with a remote UE. 

The controller UE shall add the new media by sending a SIP REFER request outside the existing dialog as specified in 
IETF RFC 3515 [32] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE 1: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and other UEs share the same 
public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) Unes in the session set as follows: 

- media Unes that are not being transferred with the port number set to zero; 

- media Une(s )that are to be added containing the media type(s) to be added and the discard port number 
"9"; and 

NOTE 2: The discard port number "9" indicates that this port number should be ignored. 

c) if the controller UE also wishes to transfer control of the collaborative session to the controller UE then the 
SIP URI additionally containing the XML body specified for the Refer-To URI in subclause 18.2.1; 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session 

5) the Contact header field containing: 

the g.3gpp.iut-controller media feature tag as described in annex C; and 

- the g.3gpp current-iut-controUer media feature tag as described in annex C set to "passive" if the controller 
UE does not wish to be the controller of the collaborative session; and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [7] and IETF RFC 3515 [32]. The controller UE shall save the media information (i.e. 
media type(s) and port number(s)) received in the sipfrag body of the SIP NOTIFY requests in order to perform further 
inter-UE transfer operations on the controllee UE. 

If error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx final 
response, the controller UE shall consider the transfer operation failed and continue the existing session with media 
components prior to the failed transfer attempt. 

The controller UE may also receive SIP NOTIFY requests as the results from the SIP SUBSCRIBE request to the 
dialog event package between itself and the SCC AS as described in clause 15. The controller UE shall save the media 
information (i.e. media type(s) and port number(s)) received in the body of the SIP NOTIFY requests in order to 
perform further inter-UE transfer operations on the controllee UE. 
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1 1 .2.2.2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session estabUshment by adding media, 
besides the procedures described in 3GPP TS 24.229 [7]. 

1 1 .3 sec AS 

11 .3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP REFER requests to provide specific functionality 
relating to the call origination: 

1) SIP REFER requests routed to the SCC AS containing: 

a) the Inter UE Transfer SCC AS URI in the Request-URI; 

b) the Target-Dialog header field with dialog identifier identifying an existing session owned by the UE sending 
the SIP REFER request; and 

c) the Refer-To header field containing a SIP URI: 

i) of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but which is 
within the Ust of UEs which can be involved within an collaborative session with the UE which originated 
the SIP REFER request; 

ii) with the SIP URI containing the URI header field with the hname "body" containing SDP for the media 
Unes with media types for at least all the media components of the existing session with one or more 
media Unes not used in the existing session and indicated with the discard port value 9; and 

iii) without method parameter or with method parameter set to "INVITE". 

In the procedures below, such SIP REFER requests are called "SIP REFER requests for establishing new media 
at controllee UE". 

NOTE 1: It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the 
request from the UE. 

2) SIP REFER requests routed to the SCC AS containing: 

a) the Inter UE Transfer SCC AS URI in the Request-URI; 

b) the Target-Dialog header field with dialog identifier identifying an existing session owned by the UE sending 
the SIP REFER request; and 

c) the Refer-To header field containing a SIP URI: 

i) of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but which is 
within the list of UEs which can be involved within an collaborative session with the UE which originated 
the SIP REFER request; 

ii) with the hname "body" URI header field containing SDP for the media lines with media types for all the 
media components of the existing session with one or more media lines used in the existing session and 
Usted with non zero port value; and 

iii) without method parameter or with method parameter set to "INVITE". 

In the procedures below, such SIP REFER requests are called "SIP REFER requests for transferring an existing 
media to controllee UE". 

NOTE 2: It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the 
request from the UE. 

If a SIP REFER request contains the Contact header field the media feature tag g.3gpp current-iut-controller set to 
"passive" and the SIP URI in the Refer-To header field contains the XML specified in annex D.3 containing a 
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<controlTransfer> element containing a <targetController> element then in the procedures below, such SIP REFER 
requests are called "SIP REFER requests for transferring control of the collaborative session". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction are handled conformant with 
3GPPTS 24.229 [7]. 

1 1 .3.2 sec AS procedures for collaborative session establishment by 
transferring media 

NOTE: If the controller UE is already involved in a collaborative session then the procedures in subclause 12.3.1 
apply. 

When the SCC AS establishes a collaborative session by transferring media as a result of receiving a SIP REFER 
request for transferring an existing media type to a controllee UE from the controller UE , the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [32]; and 

2) a SIP INVITE request to controllee UE, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

d) the SDP information for the media component to be transferred as follows: 

A) The media type(s) from the media (m=) lines from the hname "body" URI header field in the SIP URI in 
the Refer-To header field of the received SIP REFER request; and 

B) for media lines which have non zero port numbers the SDP parameters from the corresponding media 
Unes as received during the last successful SDP offer/answer exchange from the remote UE and extended 
with 

i) sendonly directionality; and 

ii) bandwidth information with RS set to zero and RR set to zero. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer and establishment of the collaborative session and continue the existing session with media 
components prior to the failed transfer attempt. 

If the SIP final response was a SIP 2xx response containing a SDP answer, the SCC AC shall send a SIP re-INVITE 
request on the dialog for the remote leg to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall: 

1) send a SIP re-INVITE request containing SDP information as follows: 

a) for the transferred media component(s), set the SDP information as from the SDP answer received in the SIP 
200 (OK) response from the controllee UE with the difference that the directionality is set to directionahty 
used by the controller UE; and 

b) for all other media components in the collaborative session, include the SDP information as from the original 
session to the remote leg. 

Upon receipt of a 2xx response for the re-INVITE request sent to the remote UE, the SCC AS shall: 

1) send a SIP re-INVITE request to the controller UE following the procedures described in 3GPP TS 24.229 [7] to 
remove the media for the transferred media component. 

Upon receiving a SIP 200 (OK) response with the SDP answer on the remote leg, the SCC AS shall send a SIP ACK 
request on the remote leg. 
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Upon receipt of a 2xx response for the re -INVITE request sent to the controller UE, the SCC AS shall send a SIP re- 
INVITE request to the controUee UE following the procedures described in 3GPP TS 24.229 [7] and set the 
directionaUty (i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the transferred media component to 
according to the SDP answer received from the remote UE. 

Upon receiving a final response to the SIP re-INVITE request which was sent towards the controUee UE to set the 
directionality attributes associated to the transferred media component, the SCC AS shall: 

1) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE; 

2) if the received response to the SIP re-INVITE is a SIP 2xx response containing an SDP answer, then include 

within the sipfrag body 

a) the Content-Type header field from the received SIP 2xx response; and 

b) the SDP answer received in the SIP 2xx response. 

1 1 .3.3 SCC AS procedures for collaborative session establishment with 
new media 

When SCC AS receives a SIP REFER request in a new dialog from the controller UE for establishing a collaborative 
session by adding new media to the controUee UE, the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the controller UE; 

2) a SIP NOTIFY request containing a sipfrag "SIP 100 Trying" as described in IETF RFC 3515 [32] to the 
controller UE; and 

3) a SIP INVITE request in accordance to 3GPP TS 24.229 [7] to the controUee UE. The SCC AS shaU construct 
the SIP INVITE request as foUows: 

a) Request-URI set to the SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from Referred-By header field of the received SIP REFER 
request if authorized by SCC AS, according to the procedures of the IETF RFC 3892 [36]; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

d) includes an SDP offer: 

A) with the media type(s) from the media (m=) lines in the same order as in the hname "body" URI header 
field of the SIP URI in the Refer-To header field of the received SIP REFER request; 

B) with port numbers of the media line(s) set to zero except the media line(s) of the new media, i.e. the 
media line(s): 

i) which were listed in the received SDP of the SIP REFER request with the discard port number "9" ; 
and 

ii) which are not used yet in the session; and 

C) for the media line(s) containing the media type(s) of the new media component(s) with additional SDP 
fields containing: 

i) sendonly directionality; 

ii) bandwidth information with RS set to zero and RR set to zero; and 

iii) a c-line set to the unspecified address (0.0.0.0) if IPv4 or a domain name within the ".invalid" DNS 
top-level domain in case of IPv6 as described in IETF RFC 6157 [43]. 

If a SIP non-2xx final response is received from the controUee UE, the SCC AS shall send a SIP NOTIFY request 
including the SIP final response as a sipfrag body to the controller UE and consider the inter-UE transfer operation 
failed. Otherwise, the SCC AS continues with the remainder of the steps described in this subclause. 
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Upon receiving a SIP 2xx response from the controllee UE with an SDP answer, the SCC AS shall send a SIP re- 
INVITE request to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP offer in the 
SIP re-INVITE request as follows: 

1) the SDP information as follows: 

a) for the added media component(s), set the SDP information as from the SDP answer received in the SIP 200 
(OK) response from the controUee UE with the difference that the directionality is set to sendrecv 
directionality; and 

b) for all other media components in the collaborative session, include the SDP information as from the original 

session to the remote leg. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer and establishment of the collaborative session. 

If the SIP final response from the remote UE was a SIP 2xx response with the SDP answer, the SCC AS shall: 

1) send to the remote UE a SIP ACK request; and 

2) send to the controllee UE a SIP re-INVITE request containing the current port number for the media component 
to be added and set the directionality (i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the 
transferred media component to according to the SDP answer received from the remote UE. 

NOTE 0: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

NOTE 1 : Any other changes such as IP address of the remote leg in case remote leg uses different IP addresses for 
different media components can also be updated in the SIP re-INVITE request. 

Upon successful completion of the SDP offer answer exchange using SIP re-INVITE request with the controllee UE, 
the SCC AS shall: 

1) send to the controllee UE a SIP ACK request 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received final response code in the sipfrag body to the controller UE and if the received response was a SIP 200 
(OK) response containing an SDP answer then also include in the sipfrag the Content-Type header field from the 
received 200 (OK) response along with the media (m=) line(s) from the SDP answer. 



1 2 Roles for media transfer within collaborative session 
for inter-UE transfer 

12.1 Introduction 

This clause specifies the roles of the controller UE, the controUee UE and the SCC AS when media transfer from the 
controller UE to a controllee UE or from a controllee UE to another controllee UE within a collaborative session. 

12.2 SCUE 

1 2.2.1 Procedures for controller UE initiated media transfer from controller 
UE to controllee UE 

12.2.1.1 Controller UE procedures 

The SC UE procedures for media transfer from controller UE to a controllee UE is the same as the procedures described 
in subclause 1 1.2.1.1 with exception that the controller UE sets the port numbers for the media types of the media 
components (in the hname "body" URI header field from the SIP URI in the Refer-To header field of the SIP REFER 
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request) which are being transferred to the controllee UE to values from the corresponding media lines received during 
the last successful SDP offer and answer exchange with the remote party. 

12.2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for media transfer from controller UE to controllee, besides the 
procedures described in 3GPP TS 24.229 [7]. 

1 2.2.2 Procedures for controller UE initiated media transfer from controllee 
UE to another controllee UE 

12.2.2.1 Controller UE procedures 

To transfer a media component within a collaborative session from one controllee UE to another controllee UE, the 
controller UE shall send a SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [32] and 

include: 

1) the Request-URl set to the Inter UE Transfer SCC AS; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE to which the media m-lines are to be transferred; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session set as follows: 

- media Unes which are not served by the target controllee UE and which are not being transferred with the 
port numbers set to zero; 

- media lines which are already served by the target controllee UE, therefore are not to be transferred 
containing the port numbers of the remote UE; and 

- media line(s) which are to be transferred containing the port numbers of the remote UE; and 

c) if the controller UE also wishes to transfer control of the collaborative session to the target controllee UE 
then the SIP URI additionally containing the XML body specified for the Refer-To URI in subclause 18.2.1; 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the collaborative session; 

5) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE; and 

6) the Contact header field containing: 

the g.3gpp.iut-controller media feature tag as described in annex C; and 

- the g.Bgpp current-iut-controUer media featiu'e tag as described in annex C set to "passive" if the controller 
UE does not wish to remain the controller of the collaborative session. 

The controller UE shall handle the subsequent SIP NOTIFY requests to the SIP REFER request according to 
3GPP TS 24.229 [7], IETF RFC 3515 [32]. 

The controller UE shall save the media information (i.e. media types(s) and port number(s)) related to the media 
component(s) received in the sipfrag body of the SIP NOTIFY requests in order to perform further inter-UE transfer 
operations on the controllee UE. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session with 
media components prior to the failed transfer attempt. 
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12.2.2.2 Controllee UE procedures 

There are no specific procedures for the controllee UE for transferring media form one controllee UE to another 
controUee UE, besides the procedures described in 3GPP TS 24.229 [7]. 

12.3 sec AS 

1 2.3.1 Procedures for controller UE initiated media transfer from controller 
UE to controllee UE 

The sec AS procedures for media transfer from the controller UE to a controllee UE is the same as the procedures 
described in subclause 11.3.2 with the exception that upon receipt of a SIP REFER request from the controller UE the 
sec AS sends a SIP re-INVITE request instead of a SIP INVITE request to the controllee UE. The SIP re-INVITE 
request is within the dialog established when establishing the collaborative session with the controllee UE. 

1 2.3.2 Procedures for controller UE initiated media transfer from controllee 
UE to another controllee UE 

When the SCC AS maintaining a collaborative session and transferring media as a result of receiving a SIP REFER 
request for transferring one ore more media components from one controllee UE to another controllee UE, the SCC AS 

shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [32] for the dialog on which the SIP REFER 
request was received; and 

2) a SIP re-INVITE request to controllee UE, to which the media component(s) is to be transferred, containing the 
SDP information for the media component to be transferred as follows: 

a) the media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in 
the Refer-To header field of the received SIP REFER request including the associated attributes (a) set to 
sendonly and the associated bandwidth information (b) with RS set to zero and RR set to zero for those 
media compontents which are to be transferred to the target controllee UE; and 

b) for media lines which have non zero port numbers the SDP parameters from the corresponding media lines as 
received during the last successful SDP offer-answer exchange from the remote UE. 

Upon receipt of a 2xx response for the re-INVITE request sent to the controllee UE to which the media component is to 
be transferred, the SCC AS shall: 

1) send a SIP re-INVITE request to controllee UE, from which the media component(s) is to be transferred, 
containing the SDP information for the media component to be transferred as follows 

a) the media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in 
the Refer-To header field of the received SIP REFER request including the associated attributes (a) set to 
sendonly and the associated bandwidth information (b) with RS set to zero and RR set to zero for those 
media components which are to be transferred to the target controllee UE; and 

b) for media hne(s) which have non zero port numbers the SDP parameters from the corresponding media lines 
as received during the last successful SDP offer-answer exchange from the remote UE;and 

2) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]. 

NOTE 1: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

If a 2xx response was received to the re-INVITE request sent to the controllee UE from which the media component(s) 
is to be transferred, the SCC AC shall send a SIP re-INVITE request to the remote UE containing an SDP body as 
follows: 
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1) for the transferred media component(s), set the SDP information as received from the SDP answer in the SIP 2xx 
response from the controllee UE to which the media component is to be transferred with the difference that the 
attributes (a) is set to directionality used by the controlee UE from which the media component was transferred; 

2) for all other media components in the collaborative session, include the associated media line(s) as from the 
original session to the remote leg. 

Upon receipt of a 2xx response for the re-INVITE request sent to the remote UE, the SCC AS shall: 

1) if the transferred media component was the only media component active at the controUee UE from which the 
media component was transferred from, send a SIP BYE request to the controUee UE from which the media 

component was transferred from; or 

2) if after the transfer of the media component the controllee UE from which the media was transferred from still 
has other media components within the collaborative session, send a SIP re-INVITE request to the controllee 
UE, from which the media component was transferred, following the procedures described in 

3GPP TS 24.229 [7] and set the port value of the associated media type(s) for the transferred media to zero. 

Upon receipt of a 2xx response for the re-INVITE request or the SIP BYE request sent to the controllee UE from which 
the media component was transferred the SCC AS shall send a SIP re-INVITE request to the controllee UE to which the 
media component was transferred following the procedures described in 3GPP TS 24.229 [7] and set the directionality 
(i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the transferred media component to according to the 
SDP answer received from the remote UE. 

Upon receiving a final response to the SIP re-INVITE request which was sent towards the controllee UE to set the 
directionaUty attributes associated to the transferred media component, the SCC AS shall: 

1) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE; 

2) if the received response to the SIP re-INVITE is a SIP 2xx response containing an SDP answer, include within 
the sipfrag body 

a) the Content-Type header field from the received SIP 2xx response; and 

b) the SDP answer as received in the SIP 2xx response. 

If any final response to a SIP re-INVITE request (apart from the SIP re-INVITE request which was sent towards the 
controllee UE to set the attributes (a) associated to the transferred media component to its previous status) was a 3xx or 
a 6xx response then the SCC AS shall consider the Inter-UE Transfer operation failed and shall send the SIP NOTIFY 
request to controller UE with the body populated with SIP/2.0 603 DecUned. 



13 Roles for release of collaborative session for inter-UE 
transfer 

13.1 Introduction 

This clause specifies the roles of controller UE, controUee UE and the SCC AS when controUer UE or the remote UE 
releases the coUaborative session. 

13.2 SCUE 

1 3.2. 1 Procedures for collaborative session release by controller UE 
13.2.1.1 Controller UE 

There are no specific procedures for the controller UE for the coUaborative session release besides the procedures 
described in 3GPP TS 24.229 [7]. 
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13.2.1.2 ControlleeUE 

There are no specific procedures for the controUee UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [7]. 

1 3.2.2 Procedures for collaborative session release by remote party 

13.2.2.1 Controller UE 

There are no specific procedures for the controller UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [7]. 

13.2.2.2 ControlleeUE 

There are no specific procedures for the controllee UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [7]. 

13.3 sec AS 

13.3.1 Procedures for collaborative session release by controller UE 

When the SCC AS receives a SIP BYE request from the controller UE for releasing a collaborative session, the SCC AS 
shall send a SIP BYE request according to the procedures described in 3GPP TS 24.229 [7] to the remote UE and to all 
controllee UEs within that collaborative session. 

1 3.3.2 Procedures for collaborative session release by remote party 

When the SCC AS receives a SIP BYE request from the remote party for releasing a collaborative session, the SCC AS 
shall send a SIP BYE request according to the procedures described in 3GPP TS 24.229 [7] to the controller UE and to 
all controllee UEs within that collaborative session. 



1 4 Roles for addition and deletion of media within 
collaborative session for inter-UE transfer 

14.1 Introduction 

This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when the controller UE or the 
remote UE adds or releases media to the collaborative session. 

14.2 SCUE 

14.2.1 Procedures for adding new media on controllee UE by controller UE 

The SC UE procedures for adding new media to a controllee UE by the controller UE is the same as the procedure 
described in subclause 1 1.2.2.1 with exception that the controller UE additionally sets the port numbers for the media 
types of the media components (in the "body" URI header field of the SIP URI in the Refer-To header field of the SIP 
REFER request) which are already served by the controllee UE to values from the corresponding media lines received 
during the last successful SDP offer and answer exchange with the remote party. 
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14.2.2 Procedures for releasing media on controllee UE by controller UE 

The controller UE may release one or more media components on a controllee UE within a collaborative session while 
it has an ongoing IMS session with a remote UE. 

The controller UE shall release the media by sending a SIP REFER request for releasing media component, including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) hnes in the session shall be set as follows: 

- media hnes that are not being released with their port numbers; and 

- media hne(s) that are to be released with the port number set to zero; 

c) if the controller UE also wishes to transfer control of the collaborative session to the controller UE then the 
SIP URI additionally containing the XML body specified for the Refer-To URI in subclause 18.2.1; 

3) the Accept header field set to "message/sipfrag" ; 

4) the Targel-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of 
the dialog between the SCC AS and the controller UE; 

5) the Contact header field containing: 

- the g.3gpp.iut-controller media feature tag as described in annex C; and 

- the g.3gpp current-iut-controUer media feature tag as described in annex C set to "passive" if the controller 
UE does not wish to remain the controller of the collaborative session; and 

6) the Referred-By header field containing a currently registered public user identity of the user to be dehvered to 
the controllee UE. 

The controller UE shall handle SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [7]. The controller UE shall save the media information (e.g. media hne number) 
received in the sipfrag body of the SIP NOTIFY request in order to perform further inter-UE transfer operations on the 
controllee UE. 

14.2.3 Procedures for releasing media on controller UE by controller UE 

If the controller UE wants to release a media component on the controller UE within a collaborative session, the 
controller UE shall follow the procedures defined in 3GPP TS 24.229 [7] for removing media with the following 
differences: 

1. include the SDP information for all other media components within the collaborative session in the SIP re- 
INVITE request; 

2. set all the port numbers of the media on the controllee UEs with value zero; and 

3. include the g.3gpp.iut-controller media feature tag as described in annex B in the Contact header field. 

14.2.4 Procedures for controller UE to remove a controllee UE from the 
collaborative session 

The controller UE may remove a controllee UE from a collaborative session while it has an ongoing IMS session with a 
remote UE. 
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The controller UE shall remove the controUee UE from the collaborative session by sending a SIP REFER request, 
including: 

1) the Request-URl set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header as follows: 

a) the SIP URI of the controUee UE; 

NOTE: The SIP URI of the controUee UE needs to be a GRUU if the controUee UE and any other UEs share the 
same public user identity. 

b) the method parameter set equal to "BYE"; 

3) the Accept header field set to include "message/sipfrag"; 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of 
the dialog between the SCC AS and the controUer UE; and 

5) the Referred-By header field containing a currently registered public user identity of the user to be deUvered to 
the controUee UE; and 

6) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex B. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
toBGPP TS 24.229 [7]. 

1 4.2.5 Procedures for releasing media component by controUee UE 

14.2.5.1 Controller UE 

When controller UE receives a SIP re-INVITE request, it can contain an SDP offer with: 

- media Unes for media components already terminated at the controller UE with non-zero port numbers; 

- media Une(s) for media components terminated at the controUee UE which is releasing the media conponent(s) 
with non-zero port number(s); and 

- media Unes for media components terminated at other controUee UEs, with port numbers set to zero. 

Upon receiving such a SIP re-INVlTE request, the controller UE shall follow the procedures described in 
3GPP TS 24.229 [7] to accept or reject the released media component(s) by the controUee UE. 

If the released media component(s) is the only media component(s) used within the collaborative session and the 
controller UE did not accept that media component, the controller UE shall release the collaborative session following 
the procedures described in 3GPP TS 24.229 [7]. 

14.2.5.2 ControUee UE 

There are no specific procedures for the controUee UE for release of media component by controUee UE, besides the 
procedures described in 3GPP TS 24.229 [7]. 

14.2.6 Procedures for modifying media on controUee UE by itself 

If the controUee UE wants to modify the characteristics of a media component on itseU within a coUaborative session, 
the controUee UE shall foUow the procedures defined in 3GPP TS 24.229 [7] for modifying media. 
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14.2.7 Procedures for adding new media by remote UE wlien tine controller 
UE does not alert the user 

When controller UE receives a SIP re-lNVlTE request within an existing dialog from the remote UE to add a new 
media component on the collaborative session, the controller UE shall decide whether adding the new media on itself or 
adding it to one of its controllee UE. 

If the controller UE decides to add the new media component on itself, the controller UE shall follow the precedure as 
specified in 3GPP TS 24.229 [7], 

If the controller UE decides to add the new media component on one of its controllee UE, the controller UE shall send a 
SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [32] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field, including: 

a) the SIP URI of the controllee UE where the media stream should be established from; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) Unes in the session shall be set as follows: 

- media Unes that are not being transferred with the port number set to zero; 

- media Une(s) that are to be added at the controUee UE the same SDP information as in the SIP re-INVITE 
request received from the remote UE. 

3) the Accept header field containing the MIME types "message/sipfiag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex B; and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle a SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [7]. Then the controller UE shall respond to the SIP re-INVITE request with a SIP 200 
(OK) response with a SDP answer as specified in 3GPP TS 24.229 [7] including in the Contact header field the 
g.3gpp.iut-controller media feature tag as described in annex B, and construct the SDP information in the SIP 200 (OK) 
response as follows: 

1) set the port number of the new added media component with value zero; and 

2) set all the ports number of the media on the controllee UEs with value zero; and 

3) for other media components on the controller UE are not changed. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and make a decision again whether adding 
the new media on itself or adding it on other controllee UE. 

14.2.8 Procedures for releasing media by remote UE 

Upon receipt of a SIP re-lNVlTE request from the remote party containing an SDP offer indicating one or more media 
components are to be released on the controller UE, the controller UE shall release the media component following the 
procedures specified in 3GPP TS 24.229 [7]. 

If the media component to be released is the last media component between the controller UE and the remote party and 
if there are more media components within the collaborative session, the controller UE shall not release the dialog with 
the SCC AS but set the port number(s) associated to the media type(s) to zero. 
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If the media component to be released is the last media component in the collaborative session, the controller UE shall 
follow the procedures described in subclause 13.2.1.1. 

14.3 sec AS 

1 4.3.0 Distinction of requests at tine SCC AS 

When SCC AS receives a SIP REFER request within a new dialog from the controller UE with: 

1) the Request-URI set to inter UE transfer SCC AS URI; 

2) the Target-Dialog header field identifies an existing dialog between the SCC AS and the controller UE; and 

3) the Refer-To header field set to SIP URI of a controUee UE and containing the URI header field with the hname 
"body" containing SDP with a media type for each of the media (m=) lines in the session as follows: 

all the media components with associated information in the session; and 

- one or more new media components which are not used in the collaborative session yet and with associated 
port number set to the discard port number "9"; 

the SCC AS shall follow the procedure in subclause 14.3.1 to add the media component to the controUee UE. 

When the SCC AS receives a SIP REFER request in a new dialog from the controller UE with: 

1) the Request-URI set to inter UE transfer SCC AS URI; and 

2) the Target-Dialog header field identifies an existing dialog between the SCC AS and the controller UE; 

3) the Refer-To header field containing the SIP URI of a controUee UE and containing the URI header field with 
the hname a "body" containing SDP with a media type for each of the media (m=) lines in the session as follows 

- all the media components with associated information in the session; and 

- the media component which is currently used in the collaborative session by the controUee UE is listed with 
port number set to 0. 

then the SCC AS shall foUow the procedure in subclause 14.3.2 to release the media component from the controUee UE. 

If a SIP REFER request contains the Contact header field the media feature tag g.3gpp current-iut-controUer set to 
"passive" and the SIP URI in the Refer-To header field contains the XML specified in annex D.3 containing a 
<controlTransfer> element containing a <targetController> element along with a <requestedBy> element then in the 
procedures below, such SIP REFER requests are caUed "SIP REFER requests for transferring control of the 
coUaborative session". 

When the SCC AS receives a SIP REFER request in a new dialog from the contoUer UE with: 

1) the Request-URI set to SIP URI of the SCC AS; 

2) the Target-Dialog header field identifies and existing dialog between the SCC AS and the controller UE; and 

3) the Refer-To header field containing the SIP URI of a controUee UE and the method parameter set equal to 
"BYE"; 

then the SCC AS shall foUow the procedure in subclause 14.3 .2B to remove the controUee UE.fiom the coUaborative 
session. 

14.3.1 Procedures for adding new media on controUee UE by controller UE 

The SCC AS procedures for adding new media on controUee UE by the controller UE is the same as the procedure 
described in subclause 1 1.3.3 with exception that upon receipt of SIP REFER request from the controller UE, the SCC 
AS generates a SIP re-INVITE request within the dialog to the controUee UE instead of SIP INVITE request. 
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14.3.2 Procedures for releasing media on controllee UE by controller UE 

When sec AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header 
indicating that a SIP INVITE request is to be sent to remove one or more media components on a controllee UE, the 
sec AS shall send: 

1) a SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with a sipfrag including SIP 100 (Trying) to the controller UE; 

3) send a SIP UPDATE request or a SIP re-INVITE request towards the remote leg as specified in 
3GPP TS 24.229 [7] with the following clarifications: 

- if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be 
released; 

- if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be 
released; 

- include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [33] for the media 
component to be released; and 

When the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from the 
remote leg the SCC AS continues with the next steps; 

NOTE 1: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due 
to media sent to closed port that could result in the release of the call. The ICMP message is specified in 
IETF RFC 792 [28]. 

1) send a SIP re- INVITE request to the controllee UE, containing an SDP offer changed using the media type(s) 
present in the hname "body" URI header field from the SIP URI in the Refer-To header; and 

2) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]. 

NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-lNVlTE request. 

Upon receiving a SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to 
the remote leg as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re- 
INVITE request as follows: 

1) set port number for each removed media component to zero; and 

2) include the SDP information for all other media components in the collaborative session as from the original 
session to the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 

1) a SIP ACK request to the remote leg; 

2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a 

sipfrag body that shall include the SIP 200 (OK) response of the SIP re-INVITE request and also include the 
Content-Type header field from the received 200 (OK) response along with the SDP answer received from the 
controllee UE. 



14.3.2A Procedures for releasing media on controller UE by controller UE 

When SCC AS receives a SIP re-lNVlTE request within an existing dialog from the controller UE to remove a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-EWITE request as follows: 

1) set port number(s) for each of the removed media component(s) to zero; and 
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2) include the SDP information for all other media components in the collaborative session as received during the 
last successful SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; 

2) a SIP 200 (OK) response to the controller UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct 
the SDP infromation in the SIP 200 (OK) response as follows: 

- set port number(s) for each of the removed media component(s) to zero; and 

- set all the ports number of the media on the controllee UEs with value zero. 

14.3.2B Procedures for controller UE removing controllee UE from the 
collaborative session 

When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header 
indicating that a SIP BYE request is to be sent to a controllee UE, the SCC AS shall send: 

1) SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and 

3) SIP UPDATE request or a SIP re-INVITE request towards the remote leg as specified in 3GPP TS 24.229 [7] 
with the following clarifications: 

- if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be 
released; 

- if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be 
released; and 

- include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [33] for the media 
component to be released. 

NOTE: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due 
to media sent to closed port that could result in the release of the call. The ICMP message is specified in 
IETF RFC 792 [28]. 

When the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from the 

remote leg the SCC AS shall send a SIP BYE request to the controllee UE to release the controlled session in 
accordance with 3GPP TS 24.229 [7] including the Referred-By header field containing the values from the Referred- 
By header field of the received SIP REFER request according to the procedures of IETF RFC 3892 [36]. 

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to the 
remote leg as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE 

request as follows: 

1) set port number(s) for each removed media component(s) to zero; and 

2) include the SDP information for all other media components in the collaborative session as from the original 
session to the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 

1) a SIP ACK request to the remote leg; 

2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a 
sipfrag body that shall include the SIP 200 (OK) response of the SIP BYE request. 
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1 4.3.3 Procedures for releasing media component initiated by controllee 
UE 

When the SCC AS receives a SIP re-INVITE request from a controllee UE containing an SDP offer with one or more 
media line(s) used on the controllee UE with port number set to zero, where the port number was previously not zero, 
the SCC AS shall send a SIP re-INVlTE request towards the controller UE containing an SDP offer with the following 
details: 

1) for the media lines on the controller UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; 

2) for the media lines on the controllee UE which were offered with port numbers set to zero in the SDP offer 
received in the re-INVITE from the controllee UE, set the port numbers to the values received during the last 
successful SDP offer and answer exchange with the remote party; and 

3) set the port number to zero for the remaining media lines. 

When the SCC AS receives a SIP BYE request from a controllee UE, the SCC AS shall send a SIP re-INVITE request 
towards the controller UE containing an SDP offer with the following details: 

1) for the media lines on the controller UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; 

2) for the media lines on the controllee UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; and 

3) set the port number to zero for the remaining media Unes. 

Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request from the controller UE and in addition to the 
procedures of 3GPP TS 24.229 [7], the SCC AS shall send a SIP re-INVITE request towards the remote party 
containing an SDP offer with: 

1) all the media lines which were not released by the controllee UE including their port numbers; and 

2) all the media hues which were released by the controllee UE set to the port numbers received in the SDP answer 
contained in the SIP 200 (OK) response from the controller UE. 

Upon receiving the SIP 200 (OK) response from the remote party, and in additon to the procedures of 
3GPP TS 24.229 [7], the SCC AS shall: 

1) if the transaction was initiated by a SIP re-INVITE request, send a SIP 200 (OK) response for the SIP re- 
INVITE request towards the controllee UE containing an SDP answer accepting the SDP offer from the 
controllee UE; or 

2) if the transaction was initiated by a SIP BYE request, send a SIP 200 (OK) response for the SIP BYE request 
towards the controllee UE. 



14.3.4 Procedures for modifying media on controllee UE by itself 

When SCC AS receives a SIP re-INVITE request within an existing dialog from the controllee UE to modify a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows: 

1) set the modified media information as the same in the SIP re-lNVlTE request received from the controllee UE; 
and 

2) include the SDP information for all other media components in the collaborative session as received during the 
last successful SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; and 
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2) a SIP 200 (OK) response to the controUee UE with an SDP answer that only contains the media component on 
the controllee UE. 



14.3.5 Procedures for adding new media by remote UE wlien tine controller 
UE does not alert the user 

When sec AS receives a SIP REFER request from the controller UE to add a new media component on a controllee 
UE, the sec AS shall send: 

1) SIP 202 (Accepted) response 

2) SIP NOTIFY request containing a sipfig for a SIP 100 (Trying) response to the controller UE as described in 
IETF RFC 3515 [32]; 

3) if the target controllee UE has not been involved in the collaborative session, send a initial SIP INVITE request 
to the controllee UE to add the controlee UE in the collaborative session, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from SIP re-INVITE request received from the remote UE; and 

d) the SDP information for the media component to be transferred as follows: 

The media type(s) from the media (m=) hnes from the hname "body" URI header field from the SIP URI 
in the Refer-To header field of the received SIP REFER request; and 

- for media lines which have non zero port numbers the SDP parameters from the corresponding media 
Unes as received in the SDP offer from the remote UE in the SIP re-INVITE request. 

4) if there are other media component within the collaborative session between the target controllee UE and the 
remote UE, send a SIP re-INVITE request to the controllee UE, containing: 

a) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]; 

b) the SDP information for the media component to be transferred as follows: 

- The media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI 
in the Refer-To header field of the received SIP REFER request; and 

- for media lines which have non zero port numbers, the SDP parameters from the corresponding media 
Unes as received in the SDP offer from the remote UE in the SIP re-INVITE request 

- for other media components that have already involved in the coUabartive session are not changed. 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received response code in the sipfrag body and if the received SIP response was a SIP 200 (OK) response containing 
an SDP answer then also include in the sipfrag the Content-Type header field from the received SIP 200 (OK) response 
along with the media (m=) lines from the SDP answer. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer. 

If the SIP final response was a SIP 200 (OK) response containing a SDP answer, the SCC AS shall: 

1) send a SIP ACK request to the controllee UE; 

2) send a SIP 200 (OK) response to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall 
construct the SDP infromation in the SIP 200 (OK) response as follows: 
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set the same SDP information for the new added media as in the SIP 200 (OK) response received from the 

controlee UE; and 

- include the SDP information for all other media in the collaborative session as received during the last 
successfiil SDP offer-answer exchange from the remote UE. 

14.3.6 Procedures for releasing media by remote UE 

Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components to be released on the controller UE, the SCC AS shall set the port number on the media line(s) which are 
not on controller UE to zero and forward the SIP re-INVITE request towards the controller UE following the 
procedures as specified in 3GPP TS 24.229 [7]. 

Upon receipt from the remote party of a SIP re-INVITE request containing an SDP offer indicating one or more media 
components to be released on the controUee UE, the SCC AS shall: 

if there are more media components left after releasing the selected media components, set the port number(s) on 
the media Une(s) which are not on the controllee UE to zero and forward the SIP re-INVITE request; or 

- if there are no more media components left after releasing the selected media components, send a SIP BYE 
request; 

towards the controllee UE following the procedures as specified in 3GPP TS 24.229 [7]. 

Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components to be released on the controller UE and one or more media components to be released on the controllee 
UE(s), the SCC AS shall: 

send a SIP re-INVITE request to the controller UE containing the SDP received from the remote end with the 
exception that the port numbers of the media components, not terminated on the controller UE, are set to zero; 

if not all the media component(s) are being released on the controllee UE, send a SIP re-INVITE request to that 
controllee UE, containing the SDP received from the remote end with the exception that the port numbers of the 
media components, not terminated on the controllee UE, are set to zero; and 

- if all the media component(s) are being released on the controllee UE, send a SIP BYE request to the controllee 
UE. 



1 5 Roles for session discovery 

15.1 Introduction 

This clause specifies the session discovery procedures of the SC UE and the SCC AS. 

15.2 SCUE 

1 5.2. 1 Discovery of sessions 

In order to discover sessions of a user, the SC UE shall send SIP SUBSCRIBE request according to 
IETF RFC 4235 [3]. The SC UE shall populate the SIP SUBSCRIBE request as follows: 

1 . the Request-URI set to the public user identity of the user; 

2. the Event header field: 

a. containing the "dialog" event package name; and 

b. the "include-session-description" header field parameter if the SC UE wants to obtain session descriptions; 
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3. the Accept-Contact header field with the g.3gpp.iut-focus media feature tag together with explicit and require; 
and 

4. the Expires header field set to zero. 

1 5.2.2 Discovery of collaborative session changes 

In order to get the information about the collaborative session changes, the controller UE shall send SIP SUBSCRIBE 
request according to IETF RFC 4235 [38]. The controller UE shall populate the SIP SUBSCRIBE request as follows: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Event header field containing the "dialog" event package name and the parameter "include-session- 
description"; 

3) the Target-Dialog header field containing the dialog information of the collaborative session; and 

4) the Expires header field set to: 

a) zero to receive one SIP NOTIFY request; or 

b) different than zero to receive the subsequent SIP NOTIFY requests. 

15.3 SCC AS 

1 5.3.1 Distinction of requests sent to the SCC AS 

The SCC AS distinguish between the following initial SIP requests: 

1) SIP SUBSCRIBE request containing: 

a) Request-URI containing the Inter UE Transfer SCC AS SIP URI; and 

b) Target-Dialog header field containing dialog information of a collaborative session belonging to the user 
identified by URI in the P-Asserted-Identity header field. 

In the procedures below, such request is known as "SIP SUBSCRIBE request for discovery of collaborative 
session changes". 

2) SIP SUBSCRIBE request containing: 

a) Request-URI with the public user identity of a served user; 

b) the Event header field with "dialog" event package name; and 

c) the Accept-Contact header field with the g.3gpp.iut-focus media feature tag along with explicit and require. 
In the procedures below, such request is known as "SIP SUBSCRIBE request for session discovery". 

Other SIP SUBSCRIBE requests can be dealt with in any manner conformant with 3GPP TS 24.229 [7]. 

1 5.3.2 SCC AS procedures for discovery of sessions 

When the SCC AS receives a SIP SUBSCRIBE request for session discovery, the SCC AS shall: 

1 . if the subscriber is not authorized to receive the dialog information of the user identified by Request-URI, then 
reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; and 

2. handle the SIP request according to IETF RFC 4235 [38] and 3GPP TS 24.229 [7]. 
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1 5.3.3 sec AS procedures for discovery of collaborative session changes 

When the SCC AS receives a SIP SUBSCRIBE request for discovery of collaborative session changes, the SCC AS 
shall handle the SIP request according to IETF RFC 4235 [38]. 



1 6 Roles for collaborative sessions involving participants 
with different subscriptions 

16.1 Introduction 

This clause specifies the collaborative session procedures in the case when users of different subscriptons participate in 
the collaborative session as controller or controllee. 

16.2 SCUE 

The procedures in subclause 1 1.2.1.1 apply. 

1 6.3 SCC AS serving the collaborative session 

Before sending the inter-UE transfer request towards the controUee UE, the SCC AS serving the collaborative session, 
shall act as follows: 

1 ) if the Contact header field contains the address of the SCC AS, insert the media feature tag g.3gpp.iut-focus as 
described in annex B.3 into the Contact header field; or 

2) if the Contact header field does not contain the address of the SCC AS, insert the feature-capabihty indicator 
g.3gpp.iut-focus into the Feature-Caps header field as described in IETF RFC 6809 [44]. 

If the SCC AS serving the collaborative session inserted the feature-capability indicator g.3gpp.iut-focus into the 
Feature-Caps header field in the inter-UE transfer request towards the controllee UE then the SCC AS serving the 
collaborative session shall include the feature-capability indicator g.3gpp.iut-focus into the Feature-Caps header field in 
any target refresh request and, in each Ixx or 2xx response to target refresh request sent to the controllee UE. 

When the SCC AS in the home network of the controllee UE receives the inter-UE transfer request containing the 
media feature tag g.3gpp.iut-focus in the Contact header field or containing the feature-capability indicator g.3gpp.iut- 
focus in the Feature-Cap header field, it will forward the inter-UE transfer request to the controllee UE without applying 
inter-UE transfer functionality. 

NOTE: The SCC AS in the home network of the controller UE takes full control of the collaborative session. 

Further SCC AS added in the home networks of controllee UEs do not influence the collaborative session 
call flows in a way which would cause additional signalling from/to the SCC AS in the home network of 
the controller UE. The SCC AS in the home network of the controller UE therefore does not need to 
distinguish whether a request is sent to / received from a controllee UE directly or via an SCC AS in the 
controllee UEs home network. 



1 7 Roles for establishnnent of a collaborative session 
during session setup 

17.1 Introduction 

This clause specifies the procedures for establishment of a collaborative session during both originating and terminating 
session setup. Procedures are specified for the controller capable UE and the SCC AS. 
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17.2 Originating session setup 

17.2.1 Controller UE 

To establish a collaborative session upon originating session setup the controller UE sends a SIP INVITE request to the 
remote party in accordance with the procedures specified in 3GPP TS 24.229 [7]. The controller UE shall populate the 
SIP INVITE request as follows: 

1) the Request-URI set to the URI of the remote party; and 

2) the SDP information as follows: 

a) for the media component(s) served by itself, the port numbers of the UE; and 

b) for the media component(s) to be estabhshed in the controUee UE, as follows: 

- the port numbers set to non zero; 

- the connection address set to 0.0.0.0 in case of IPv4 or set to domain name within the ".invalid" DNS top- 
level domain in case of IPv6 as described in IETF RFC 6157 [43]; and 

- "a=3gpp.iut.controUee" attribute set to the SIP URI of controUee UE. 

Upon receiving a SIP 200 (OK) response with the SDP answer from SCC AS, the controller UE shall send a SIP ACK 
request to the SCC AS. 

1 7.2.2 SCC AS serving the collaborative session 

Upon receiving a SIP INVITE request including SDP containing media with the "a=3gpp.iut.controllee" attribute, the 
SCC AS shall send a SIP INVITE request to the controUee UE including: 

1) the Request-URI set to the URI of the controUee UE which is indicated in the "a= 3gpp. iut.controUee" attribute; 

2) the P-Asserted-Identity header field set to the URI of the controller UE; and 

3) the SDP information as follows: 

a) for the media component(s) that are to be estabhshed on the controller UE containing the port number set to 

zero; and 

b) for the media component(s) that are to be established on the controUee UE: 

- set the cormection address to 0.0.0.0 in case of IPv4 or set to domain name within the ".invaUd" DNS top- 
level domain in case of IPv6 as described in IETF RFC 6157 [43]; 

set the port number to non zero; and 

- remove the attribute "a=3gpp.iut.controllee". 

Upon receiving a SIP 18x provisional response or a SIP 2xx successful response from the controUee UE that includes an 
SDP answer, the SCC AS shall send a SIP INVITE request to the remote party including: 

1) the Request-URI set to the URI of the remote party using the URI from the Request-URI of the original SIP 
INVITE request; 

2) the P-Asserted-Identity header field set to the URI of the controller UE; and 

3) the SDP information as follows: 

a) for the media component(s) that are to be estabhshed on the controller UE containing the port number set to 
the port numbers of the controller UE; and 

b) for the media component(s) that are to be estabhshed on the controUee UE containing the port number for the 
corresponding media received in the media line of the SDP received during the last successful SDP 
offer/answer exchange. 
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Upon receiving a SIP 18x provisional response or a SIP 2xx successful response from the remote UE, the SCC AS shall 
forward the SIP 18x provisional response or a SIP 2xx successful response to the controller UE and send a SIP re- 
INVTE/UPDATE request to the controllee UE to update the media description based upon the last successful SDP 
offer/answer exchange with the remote party. 

Upon receiving a SIP 200 (OK) response from the controllee UE, the SCC AS shall send a SIP ACK request to the 
controllee UE. 

Editor's Note: When the SCC AS acts as the third party call controller, the relationship between the header fields 
received in a SIP message and those in the SIP message generated as a result needs to be described. In 
particular this needs to cover actions on the Privacy header field. 

Upon receiving the second (and the subsequent) SIP 18X response from the second (and the subsequent) remote UE 
that includes a SDP answer, the SCC AS determines that the call is forked as specified in IETF RFC 3261 [30] and shall 
perform as follows: 

1) if the SCC AS has not yet received any SIP 200 (OK) response from any remote UE for the collaborative 
session, the SCC AS shall save the SIP 18X response without sending a SIP re-INVITE/UPDATE message to 
the controllee UE and update the remote UE on the availability of resources at the controller UE and the 
controllee UE; and 

2) if afterwards, the SCC AS receives a SIP 200 (OK) response from the second (or one of the subsequent) remote 
UE before or without receiving any SIP 200 (OK) response from any other remote UE, the SCC AS shall 
forward the SIP 200 (OK) respose to the controller UE and send a SIP re-INVTE/UPDATE request to the 
controllee UE for media re-negotiation with the remote UE based on the saved SIP 18X response from the 
remote UE that sends the SIP 200 (OK) response. Thus a collaborative session is established between the remote 
UE that first sends the SIP 200 (OK) response and the controller/controUee UE. 

17.3 Terminating session setup 
1 7.3.1 Controller capable UE 

Upon receiving a SIP initial INVITE request from the remote party, the controller capable UE shall send a SIP 300 
(Multiple Choices) response to the SIP initial INVITE request in accordance with the procedures specified in 
3GPP TS 24.229 [7] as follows: 

1) a Contact header field for each UE that is to be a participant in the collaborative session (including the controller 
capable UE if the controller capable UE is also a participant) containing the SIP URI of that UE 

NOTE: The SIP URI of the UE needs to be a GRUU if any of the UEs that are participants of the collaborative 
session share the same public user identity. 

2) a Content-Type header field containing the MIME type application/vnd.3gpp.iutH-xml; and 

3) an application/vnd.3gpp.iutH-xml MIME body containing a <controlTransfer> element that contains: 

i) an <activeController> element containing the SIP URI of the controller UE for the collaborative session and 
additionally containing the URI header field with the hname "body" containing SDP for the media type for 
each of the media (m=) lines in the session set as follows: 

media lines that are not being assigned to the controller capable UE with the port number set to zero 

media line(s) that are to be assigned to the controller capable UE containing the port number for the 
corresponding media types received in the media line of the SDP offer in the SIP INVITE request; and 

ii) a <Controllee> element for each controllee UE that is to be a participant in the collaborative session 
containing the SIP URI of the controllee UE for the collaborative session and additionally containing the URI 
header field with the hname "body" containing SDP for the media type for each of the media (m=) lines in 
the session set as follows: 

media Unes that are not being assigned to that controllee UE with the port number set to zero 



ETSI 



3GPP TS 24.337 version 10.8.0 Release 10 



45 



ETSI TS 124 337 VI 0.8.0 (2013-07) 



media line(s) that are to be assigned to that controllee UE containing the port number for the 
corresponding media types received in the media line of the SDP offer in the SIP INVITE request; 

If the controller capable UE indicated in the SIP 300 (Multiple Choices) response that it will be a participant in the 
collaborative session then the controller capable UE will receive a SIP INVITE request containing an SDP offer . The 
controller capable UE shall handle the SIP INVITE request in accordance with the procedures specified in 
3GPP TS 24.229 [7]. 

If the controller capable UE indicated in the SIP 300 (Multiple Choices) response that it will be the controller UE for 
the collaborative session then the controller capable UE shall when accepting the session behave as a controller UE of 
the collaborative session, otherwise the controller capable UE shall act as a controllee UE for the collaborative session. 

1 7.3.2 sec AS serving the collaborative session 

When forwarding an initial SIP INVITE request from the remote party to the controller capable UE the SCC shall add 
an Accept header field containing the MIME type application/vnd.3gpp.iut+xml to the SIP INVITE request. 

Upon receiving a SIP 300 (Multiple Choices) response containing the MIME body application/vnd.3gpp.iut+xtnl from 
the controller capable UE in response to the initial SIP INVITE request, the SCC AS shall: 

1) send a SIP ACK request to the controller capable UE in accordance with the procedures specified in 
3GPPTS 24.229 [7]; 

2) authorise the request for the collaborative session setup with the controllee UE(s) identified in the <controllee> 
element in the MIME body of the SIP 300 (Multiple Choices) response; and 

3) consider the UE identified in <activeController> element in the MIME body of the SIP 300 (Multiple Choices) 
as the controller UE for the collaborative session. 

If authorised the SCC AS shall send a SIP 183 (Session Progress) response to the remote UE containing an SDP answer 
as follows: 

1) for all media lines indicated in the MIME body of the SIP 300 (Multiple Choices) response, set the port numbers 

to the discard port number "9" and set to "a=inactive"; and 

2) for any media lines in the original SDP offer that are not indicated in the MIME body of the SIP 300 (Multiple 

Choices) response, set the port numbers to zero. 

To establish the media the SCC AS shall send a SIP INVITE request to each UE identified in the Contact header fields 
of the SIP 300 (Multiple Choices) response including: 

1) the Request-URI set to the URI of the UE from a Contact header field of the SIP 300 (Multiple Choices) 

response; 

2) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE in the original SIP INVITE request; and 

3) the SDP information for the media component to be transferred to that UE as follows: 

a) the media type(s) from the media (m=) lines from the hname "body" URI header field in the corresponding 
SIP URI in the <activeController> element and <controllee> element(s) in the <controlTransfer> element of 
the application/vnd.3gpp.iut+xml MIME body of the SIP 300 (Multiple Choices) response; and 

b) for media lines which have non zero port numbers the SDP parameters from the corresponding media lines as 
received in the SDP offer from the remote UE and extended with 

i) sendonly directionaUty; and 

ii) bandwidth information with RS set to zero and RR set to zero. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and the 
SCC AC shall send to the controller capable UE either a SIP re-INVITE request if a 2xx response has been received 
from the controller UE or a SIP UPDATE request if a final response has not yet been received from the controller 
capable UE following the procedures described in 3GPP TS 24.229 [7] as follows: 
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1) containing SDP reoffering the media component(s) that were offered to the UE that did not accept the SDP offer. 

If a response containing an SDP answer is received from a local UE, the SCC AC shall send a SIP UPDATE request on 
the dialog for the remote leg to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall: 

1) send a SIP UPDATE request containing SDP information as follows: 

a) for the transferred media component(s), set the SDP information as from the SDP answer received in the 
response from the UE; and 

b) for all other media components in the collaborative session, include the SDP information as from the 
previous offer answer exchange with the remote leg. 

Upon receipt of a 2xx response for the SIP UPDATE request sent to the remote UE, the SCC AS shall send a SIP 
UPDATE request to the local UE that terminates the media component accepted in the SDP answer from the remote UE 
following the procedures described in 3GPP TS 24.229 [7] and set the directionaUty (i.e. 

sendrecv/sendorily/recvonly/inactive) attributes associated to the transferred media component to according to the SDP 
answer received from the remote UE. 

Upon receipt of a 2xx response for the SIP INVITE request sent to the controller capable UE, the SCC AS shall send a 
SIP 2xx response to the remote UE following the procedures described in 3GPP TS 24.229 [7] to estabUsh the session 
with the remote UE. 

Upon receiving a SIP ACK request from the remote UE, the SCC AS shall send a SIP ACK request to each local UE 
once a SIP 200 (OK) response has been received from the local UE. 



1 8 Roles for assignment and transfer of control of a 
collaborative session 

18.1 Introduction 



This clause specifies the roles of controller UE, controller capable UE and the SCC AS when a controller UE transfers 
control of the collaborative session to another UE. The procedures in this clause may be combined with the procedures 
for adding, transferring or removing media on the controUee UE as specified in subclauses 11.2, 12.2 and 14.2 in order 
to transfer control while adding, transferring or removing media. 



To transfer control of the collaborative session the controller UE shall send a SIP REFER request outside the existing 

dialog as specified in IETF RFC 3515 [32] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the UE that is requested to become a controller of the collaborative session; and 

NOTE: The SIP URI of the UE that is requested to become a controller of the collaborative session needs to be a 
GRUU if the UE that is requested to become a controller of the collaborative session and any other UEs 
share the same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing the XML 
specified in annex C.2 containing a <controlTransfer> element containing a <targetControIler> element 
containing the SIP URI of the UE that is requested to become a controller of the collaborative session; 

3) the Accept header field containing the MIME type "message/sipftag"; 



18.2 



SCUE 



18.2.1 



Controller UE 
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4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; 

5) the Contact header field containing: 

- the g.Sgpp.iut-controUer media feature tag as described in annex B.2; and 
- the g.3gpp.current-iut-controUer media feature tag as described in annex B.4 set to "passive". 

6) the Referred-By header field containing a currently registered public user identity of the user to be deUvered to 
the UE that is requested to become a controller of the collaborative session. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [7] and IETF RFC 3515 [32]. The controller UE shall examine the Contact header field 
included in the sipfrag of the SIP 200 OK response in the SIP NOTIFY of the refer events package and if that Contact 
header field contains the g.3gpp.current-iut-controller media feature tag set to "active" then control has been 
successfully transferred and the controller UE shall perform the role of a controUee UE in the collaborative session, 
otherwise the controller UE shall consider the control transfer operation failed and continue as the controller of the 
collaborative session. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the control transfer operation failed and continue as the controller of the 
collaborative session. 

1 8.2.2 Controller capable UE 

When the controller capable UE receives a SIP INVITE request or a SIP re-INVITE request containing a 
multipart/mixed MIME body containing a SDP offer and an XML body containing a <controITransfer> element as 
specified in annex C.2 the controller capable UE shall when accepting the SDP offer send a SIP 200 (OK) response 
according to the procedures described in 3GPP TS 24.229 [7]. 

NOTE 1: The controller capable UE uses the media lines in the SDP offer to identify all the media types involved 
in the collaborative session and their order in the SDP for the collaborative session. 

If the <controlTransfer> element contains a <targetController> element containing the SIP URl of this controller 
capable UE the controller capable UE shall determine whether to accept control of the collaborative session. 

NOTE 2: Determining whether to accept control of the collaborative session could require interaction with the user. 

If the controller capable UE accepts control of the collaborative session the controller capable UE shall include the 
media feature tag g.3gpp.current-iut-controller set to "active" in the Contact header of the SIP 200 OK response and 
assume the role of controller of the collaborative session. 

If the controller capable UE does not accept the SDP offer or rejects the SIP INVITE request with a 3xx, 4xx, 5xx or 
6xx response, the controller capable UE shall not assume the role of controller of the collaborative session. 

18.3 sec AS 

18.3.1 Procedures for transferring control of the collaborative session 

When the SCC AS transfers control of a collaborative session as a result of receiving a SIP REFER request for 
transferring control of the collaborative session, the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [32]; and 

2) a SIP INVITE request or SIP re-lNVlTE request to the UE identified by the SIP URI in the Refer-To header 
field, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]; 
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c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; 

d) the Content-Type header field set to the MIME type "multipart/mixed"; and 

e) a "multipart/mixed" MIME body containing the following MIME parts: 

i) the Content-Type header field set to "application/sdp" and SDP information as follows: 

I) if there are media (m=) lines in the hname "body" URI header field in the SIP URI in the Refer-To 
header field of the received SIP REFER request then: 

include the media type(s) from the media (m=) lines from the hname "body" URI header field in 
the SIP URI in the Refer-To header field of the received SIP REFER request; and 

- if any media (m=) lines from the hname "body" URI header field in the SIP URI in the Refer-To 
header field of the received SIP REFER request are set to non zero port numbers and the 
corresponding media component is not already on the UE to which control is being transferred 
then additionally follow the procedures in subclause 1 1.3.2, or subclause 12.3.1, or 
subclause 19.3.2 for transferring media or subclause 11.3.3 for adding media based on the 
determination procedure in 1 1 . 3 . 1 ; 

II) if there are not any media (m=) lines in the hname "body" URI header field in the SIP URI in the 
Refer-To header field of the received SIP REFER request then include the media lines and attributes 
as agreed in the last SDP offer answer exchange with the UE identified by the SIP URI in the Refer- 
To header field; 

ii) the Content-Type header field set to "application/vnd.Sgpp.iut-nxml" along with the handling parameter 
set to optional and the XML document from the hname "body" URI header field in the SIP URI in the 
Refer-To header field of the received SIP REFER request. 

If the SIP final response to the SIP INVITE request or SIP re-INVITE request was a non 2xx response then the SCC AS 
shall consider the transfer of control operation failed and abort the transfer of control of the collaborative session and 
continue the existing session with media components and controller UE prior to the failed transfer attempt. 

Upon receiving a final response to the SIP INVITE request or SIP re-INVITE request which was sent towards the 
controller capable UE, the SCC AS shall: 

1) send a SIP ACK request to the controller UE that sent the final response; 

2) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE 
that sent the SIP REFER request; 

3) if the received response is a SIP 2xx response containing an SDP answer, then include within the sipfrag body 

a) the Contact header field from the received SIP 2xx response including the media feature tags; 

b) the Content-Type header field from the received SIP 2xx response; and 

c) the SDP answer received in the SIP 2xx response; and 

4) if the Contact header field from the received SIP 2xx response contains the media feature tag g.3gpp.current-iut- 
controUer set to "active" then consider the UE that sent the SIP 2xx response as the controller of the 
collaborative session. 



The following subclauses describe the procedures and call flows of media flows transfer initiated by the target UE and 
by a UE other than the target UE. 



19 



Roles for media flow transfer 
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19.2 SCUE 

19.2.1 Media flows transfer initiated by a UE not participating in tlie 
ongoing collaborative session 

For requesting media transfer to the requesting UE (the target UE), the target UE sends a SIP REFER to the controller 
UE in the ongoing collaborative session with transferred media. The SIP REFER request includes: 

NOTE 1 : Before requesting media flow transfer, the target UE of media transfer discovers the ongoing 

collaborative session with transferred media and gets information about its media flows by subscribing to 
dialog event. 

1) the Request-URI set to the SIP URI of the controller UE in the ongoing collaborative session with transferred 
media; 

NOTE 2: The SIP URI of the controller UE needs to be a GRUU if multiple UEs share the same public user identity. 

2) the Refer-To header field set as follows: 

a) The SIP URI of the Target UE; 

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target UE and any other UEs share the same 
public user identity. 

b) the SIP URI additionally containing the URI header field with the hname 'body' containing SDP for the 
media type for each of the media (m=) lines in the session set as follows: 

- Media lines which are not being transferred with the port numbers set to zero 

- Media lines which are to be transferred containing the port number of the Remote UE; 

3) the Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with 

explicit and require tags; 

4) the Accept header field containing the MIME type 'message/sipfrag'; 

5) the Target-Dialog header field containing the dialog parameters for the dialog of the ongoing collaborative 
session with the transferred media; and 

NOTE 4: The dialog parameters are obtained by subscribing to dialog event package. 

6) the Referred-By header field containing a currently registered public user identity of the user. 

19.2.2 Media flow transfer initiated by a UE not participating in the ongoing 
collaborative session - media on controllee UE 

The procedures of the SC UE are identical as described in subclause 19.2.1. 

19.2.3 Media flows transfer initiated when no collaborative session has 
been established 

To transfer a media component when no collaborative session has been established, the Target UE shall send a SIP 
REFER request to the SCC AS as specified in IETF RFC 3515 [5] and include: 

NOTE 1: Before requesting media flow transfer, the target UE of media transfer discovers the ongoing session with 
transferred media and gets information about its media flow by subscribing to dialog event. 

1) the Request-URI set to the SIP URI of the local UE that currently holds the media for the session; 

NOTE 2: The SIP URI of the local UE need to be a GRUU if multiple UEs share the same public user identity. 

2) the Refer-To header field set as follows: 
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a) the SIP URI of the Target UE to which the media m-lines are to be transferred; and 

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target UE and any other UEs share the same 
public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session set as follows: 

media lines which are not being transferred with the port numbers set to zero; and 

- media Unes which are to be transferred containing the port numbers of the remote UE. 

3) an Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with 

explicit and require tags; 

4) an Accept header field containing the MIME type "message/sipfrag"; 

5) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and 
NOTE 4: The dialog parameters are obtained by subscribing to the dialog event package. 

6) the Referred-By header field containing a currently registered public user identity of the user. 

1 9.2.4 Media flows transfer initiated by a controllee UE of an ongoing 
collaborative session 

The controllee UE initiates the transfer of Media flow from the controller UE to itself by sending a SIP REFER request 
to the sec AS outside the existing dialog as specified in IETF RFC 3515 [5] and include: 

NOTE 1 : Before requesting media flow transfer, the target UE of media transfer discovers the ongoing session with 
transferred media and gets information about its media flow by subscribing to dialog event. 

1) the Request-URI set to the SIP URI of the local UE that currently holds the media for the session; 

NOTE 2: The SIP URI of the local UE needs to be a GRUU if multiple UEs share the same public user identity. 

2) The Refer-To header field set as follows: 

a) The SIP URI of the Target UE; 

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target UE and any other UEs share the same 
public user identity. 

b) the SIP URI additionally containing the URI header field with the hname 'body' containing SDP for the 
media type for each of the media (m=) Unes in the session set as follows: 

Media lines which are not being transferred with the port numbers set to zero; 

Media lines which are to be transferred containing the port number of the Remote UE. 

3) The Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with 

explicit and require tags; and 

4) The Accept header field containing the MIME type 'message/sipfrag'; and 

5) The Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and 
NOTE 4: The dialog parameters are obtained by subscribing to the dialog event package. 

6) The Referred-By header field containing a currently registered public user identity of the user. 

19.2.5 Controllee UE initiated addition of media to another controllee UE 

For requesting addition of media to another controllee UE, the requesting controllee UE sends a SIP REFER request to 
the controller UE. The SIP REFER request includes: 
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NOTE 1 : Before requesting addition of media, the requesting controllee UE of addition of media discovers the 

ongoing collaborative session and gets information about its media flows by subscribing to dialog event. 

1) the Request-URI set to the SIP URI of the controller UE in the ongoing collaborative session to be added media; 

NOTE 2: The SIP URI of the controller UE needs to be a GRUU if the controller UE and any other UEs share the 
same public user identity. 

2) the Refer-To header field set as follows: 

a) the SIP URI of the target UE; 

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target UE and any other UEs share the same 

public user identity. 

b) the SIP URI additionally containing the URI header field with the hname 'body' containing SDP for the 
media type for each of the media (m=) Unes in the session set as follows: 

- media lines which are not served by the target controllee UE and which are not being added with the port 
numbers set to zero; 

- media lines which are already served by the target controllee UE, therefore are not to be added containing 
the port numbers of the remote UE; and 

- media line(s) that are to be added containing the media type(s) to be added and the discard port number 
"9" 

3) the Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with 

explicit and require tags; 

4) the Accept header field containing the MIME type 'message/sipfrag'; 

5) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and 
NOTE 4: The dialog parameters are obtained by subscribing to the dialog event package. 

6) the Referred-By header field containing a currently registered public user identity of the user. 

19.3 sec AS 

19.3.1 Media flows transfer initiated by a UE not participating in tlie 
ongoing collaborative session 

On receiving the SIP REFER request, the SCC AS requests the controller UE to authorize the pull request or the SCC 
AS authorizes the request on behalf of the controller UE (e.g. pre -configured). 

The SCC AS performs the steps as described in subclause 12.3.1, except that the SCC AS sends: 

- a SIP INVITE request to the controllee UE to which the media component(s) is to be transferred (i.e. the target 
UE), instead of a SIP re-INVITE request; and 

- the SIP 202 (Accepted) response and SIP and SIP NOTIFY request to the target UE instead of the controller UE. 

1 9.3.2 Media flow transfer initiated by a UE not participating in the ongoing 
collaborative session - media on controllee UE 

On receiving the SIP REFER request, the SCC AS requests the controller UE to authorize the pull request or the SCC 
AS authorizes the request on behalf of the controller UE (e.g. pre-configured). 

The SCC AS performs the steps as described in subclause 12.3.2, except that the SCC AS sends: 

a SIP INVITE request to the controllee UE to which the media component(s) is to be transferred (i.e. the target 
UE), instead of a SIP re-INVITE request; 
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- the SIP 202 (Accepted) response and SIP NOTIFY request to the target UE instead of the controller UE. 

19.3.3 Media flows transfer initiated wlien no collaborative session has 
been established 

On receiving the SIP REFER request, the SCC AS requests the local UE to authorize the pull request or the SCC AS 
authorizes the request on behalf of local UE (e.g. pre-configured). 

The SCC AS performs the steps as described in subclause 1 1.3.2, except that the SIP 202 (Accepted) response and SIP 
NOTIFY request are sent to the target UE instead of the local UE. 

1 9.3.4 Media flows transfer initiated by a controllee UE of an ongoing 
collaborative session 

On receiving the SIP REFER request, the SCC AS requests the local UE to authorize the pull request or the SCC AS 
authorizes the request on behalf of the local UE (e.g. pre-configured). 

The SCC AS performs the steps as described in subclause 12.3.1, except that the SIP 202 (Accepted) response and SIP 
NOTIFY request are sent the target UE instead of the local UE. 

1 9.3.5 Controllee UE initiated addition of media to another controllee UE 

On receiving the SIP REFER, the SCC AS requests the controller UE to authorize the adding media request or the SCC 
AS authorizes the request on behalf of the controller UE (e.g. pre-configured). 

The SCC AS performs the steps as described in subclause 14.3.1, except that the SIP 202 (Accepted) response and SIP 
NOTIFY request are sent tothe UE that sent the SIP REFER request instead of the controller UE. 

20 Roles for session replication / media replication 
performed by the SCC AS 

20.1 General 

The "3gpp.iut.replication" SDP attribute is used to indicate replication of a media component. 

a = 3gpp.iut.replication 

The replication attribute may be included either at the session level or at the media level. Inclusion of 
"a=3gpp.iut.replication" at the session level indicates replication of all media components included in the SDP. 
Inclusion of "a=3gpp.iut.replication" at the media level indicates repUcation of the specific media component that the 
attribute is associated with. 

20.2 Session replication / media replication performed by the 
SCC AS - pull mode 

20.2.1 SC UE 

In order to replicate an existing session, the UE shall send a SIP INVITE request to the SCC AS. The SIP INVITE 
request shall include: 

NOTE 1: Before requesting repUcation, the UE discovers the ongoing collaborative session with the replicated 
media and gets information about its media flows by subscribing to the dialog event package. 

1) the Request-URI set to the SIP URI of the controller UE in the ongoing collaborative session with transferred 
media; 
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NOTE 2: The SIP URI of the controller UE needs to be a GRUU if multiple UEs share the same public user identity. 

2) the Accept-Contact header field containing the g.3gpp.iut-focus media feature tag with explicit and require tags; 

3) the Target-Dialog header field containing the dialog parameters for the dialog of the ongoing collaborative 
session with the rephcated media; and 

4) SDP information as follows: 

a) for the replicated media component(s), containing the port numbers of the UE and the "a= 3gpp. 
iut.replication" attribute which indicates that the rephcation request is sent from the controllee UE and it uses 
the network based solution; 

b) for the media component(s) served by the UE itself, containing the port numbers of the UE; and 

c) for the media component(s) not served by the UE, containing the port numbers set to zero. 

Upon receiving the SIP 2xx response for the INVITE request from the SCC AS, the UE shall send a SIP ACK request 
to the SCC AS. 

20.2.2 SCC AS serving the collaborative session 

On receiving the SIP INVITE request, the SCC AS authorizes the request and sends information to the MRF to allocate 
the media resource for the media to be replicated. The MRF is requested to provide mixup functionahty to support it. 

If the SIP INVITE request has been authorized, the SCC AS shall send a SIP re-INVTE request to the controller UE to 
update the access leg on the controller UE for the rephcated media flow with the MRF. The SIP re-INVITE request 
includes the SDP offer with the "a= 3gpp. iut.replication" attribute. 

Upon receiving a SIP 200 (OK) response with the SDP answer from the controller UE, the SCC AS shall send a SIP 
ACK request to the controller UE. After that, the SCC AS shall send a SIP re-INVITE request on the dialog for the 
remote leg to the remote UE to update the remote leg to connmunicate media with the MRF. 

Upon receiving a SIP 200 (OK) response with the SDP answer on the remote leg, the SCC AS shall send a SIP ACK 
request on the remote leg. 

20.3 Session replication / media replication performed by the 
SCC AS - push mode 

20.3.1 SC UE 

In order to replicate an existing session to another UE, the SC UE shall send a SIP REFER request as specified in 
IETF RFC 3515 [32] and include: 

1) the Request-URI set to the inter UE Transfer SCC AS URI; 

2) the Accept-Contact header field containing the g.3gpp.iut-focus media feature tag with expUcit and require tags; 

3) the Target-Dialog header field containing the dialog parameters for the dialog of the ongoing collaborative 
session with the replicated media; and 

4) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) hnes in the session set as follows: 

- media hnes that are not being replicated with the port number set to zero; and 
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media line(s) that are to be replicated containing the "a= 3gpp.iut.replication" attribute which indicates 
that the replication request was sent from the controller UE and it uses the network based solution. 

Upon receiving a SIP re-INVITE request from the SCC AS, the UE shall send a SIP 200 (OK) response to the SCC AS 
to confirm the successful media update. 

Upon receiving a SIP NOTIFY request from the SCC AS, the UE shall send a SIP 200 (OK) response to the SCC AS. 

20.3.2 SCC AS serving the collaborative session 

Upon receiving a SIP REFER request due to session replication, the SCC AS shall: 

1) if not authorized, reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining 
steps; 

2) send information to the MRF to allocate the media resource for the media to be replicated; and 

3) send a SIP INVITE request to the controUee UE including: 

a) the Request-URI with the SIP URI from the Refer-To header field of the received SIP REFER request; and 

b) the SDP information as follows: 

- the media type(s) that are to be replicated from the media (m=) lines from the hname "body" URI header 
field in the SIP URI in the Refer-To header field of the received SIP REFER request and the "a= 
3gpp.iut.replication" attribute. 

Upon receiving a SIP 200 (OK) response with the SDP answer from the controUee UE, the SCC AS shall send a SIP 
ACK request to the controUee UE. After that, the SCC AS shall send a SIP re-INVITE request to controller UE to 
update the access leg for the replicated media flow with the MRF. 



21 Roles for session replication / media replication 
performed by the remote UE 



21.1 General 

This clause specifies the SC UE and SCC AS procedures for: 

the push mode session replication / media replication performed by the remote UE; and 

- the pull mode session replication / media replication performed by the remote UE. 
This solution: 

assumes that the existing dialog does not need to be indicated in session replication as all sessions established 
towards a URI of the remote UE provide the same media, e.g. an INVITE to a URI identifying a movie at an AS 
will always result to playback of the same movie. 

- does not require extension of remote UE as playback state is exchanged between the SC UEs. 



21 .2 Session replication / media replication performed by the 
remote UE - pull mode 

21.2.1 Introduction 

This clause specifies the SC UE and SCC AS procedures for the pull mode session replication / media replication 
performed by the remote UE. 
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21.2.2 SCUE 

21 .2.2.1 SC UE not participating in the session to be replicated 

21 .2.2.1 .1 Triggering pull mode session replication 

The SC UE shall fetch the dialog information of a UE as described in clause 15 and select an existing session for 
replication. 

In order to replicate the session, the SC UE: 

1. shall send a SIP INVITE request according to 3GPP TS 24.229 [7J. The SC UE shall populate the SIP INVITE 
request as follows: 

A. the Request-URI is set to the remote URI (as defined in IETF RFC 3261 [30]) of the existing session; and 

B. SDP offer containing the same media components as used in the existing session selected for replication. 

21 .2.2.1 .2 Requesting playback state 

In order to get playback state from another UE participating in an existing session, the SC UE shall send a SIP REFER 
request as specified in IETF RFC 3515 [32] and 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER 
request as follows: 

1. the Request-URI set to the URI of the UE participating in the existing session; 
NOTE 1 : The URI of the UE needs to be a GRUU if several UEs share the same identity. 

2. the Refer-To header field set to the own SIP URI extended with: 

NOTE 2: The own SIP URI needs to be a GRUU if several UEs share the same identity. 

A. method parameter set to "MESSAGE"; and 

B. In-Reply-To URI header field set to the value of the Call-Id header field of the SIP REFER request; 

3. the Target-Dialog header field set to the dialog identifier of the session whose playback state is to be provided; 
NOTE 3: The dialog identifiers of sessions of other UEs can be found using dialog event package subscription. 

4. the Require header field populated with the option tag value "tdialog"; and 

5. application/vnd.3gpp.repUcation-i-xml MIME body containing the playback state parameters to be provided. 
The SC UE receives the playback state upon receiving SIP MESSAGE request with: 

1 . In-Reply-To header field containing the call-id of the dialog of the subscription created by SIP REFER request; 
and 

2. application/vnd.3gpp.repUcationH-xml MIME body. 



Upon receiving SIP REFER request containing: 

1 . the Refer-To header field containing a SIP URI with method parameter equal to "MESSAGE" ; 

2. the Target-Dialog header field containing the dialog identifier of an existing session with playback state; and 

3. application/vnd.3gpp.replicationH-xml MIME body containing the playback state parameters to be provided; 



21.2.2.2 



SC UE participating in the session to be replicated 



21.2.2.2.1 



Providing playback state on request of other UE 
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then the SC UE shall handle the SIP REFER request as specified in 3GPP TS 24.229 [7] and IETF RFC 3515 [32]. The 

UE shall populate the SIP MESSAGE request with 

1. header fields which were included as URI header fields in the URI in the Refer-To header field of the received 
SIP REFER request; and 

2. application/vnd.3gpp.repUcation+xmI MIME body containing the playback state of the session identified by 
Target-Dialog header field as requested in the application/vnd.3gpp.replication-Hxnil MIME body included in the 
REFER request. 

21.2.3 sec AS 

21 .2.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following SIP requests to provide specific functionality related to session 
replication: 

1 . SIP REFER request routed to the SCC AS due to the terminating filter criteria: 

A. where the Refer-To header field contains a SIP URI with method parameter set to "MESSAGE"; and 

B. containing application/vnd.3gpp.replication+xnil MIME body. 

In the procedures below, such request is known as "SIP REFER request for providing playback state". 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [7]. 

21 .2.3.2 Providing playback state on request of otiier UE 

Upon receiving a SIP REFER request for providing playback state, the SCC AS shall: 

1. if not authorized, reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining 

steps; and 

2. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [7]. 

21 .3 Session replication / media replication performed by the 
remote UE - push mode 

21.3.1 Introduction 

This clause specifies the SC UE and SCC AS procedures for the push mode session rephcation / media replication 
performed by the remote UE. 

21.3.2 SCUE 

21 .3.2.1 SC UE participating in the session to be replicated 
21 .3.2.1 .1 Triggering push mode session replication request 

In order to replicate an existing session of this SC UE to other UE, the SC UE shall send a SIP REFER request as 
specified in IETF RFC 3515 [32] and 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER request as 
follows: 

1. the Request-URI set to the URI of the UE where the session is to be replicated; 
NOTE: The URI of the UE needs to be a GRUU if multiple UEs share the same identity. 
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2. the Refer-To header field set: 

A. if the asserted remote UE identity of the existing session is known, then to the asserted remote UE identity of 
the existing session; and 

B. if the asserted remote UE identity of the existing session is not known, then to the remote URI (as defined in 
IETF RFC 3261 [30]) of the existing session; 

and extended with the following URI header fields: 

A. if the session is established using an IMS communication service that requires the use of an IMS 
communication service identifier: 

a. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS 
connmunication service identifier of the existing session; and 

b. the P-Preferred-Service header field set to the IMS connmunication service identifier of the existing 
session; and 

B. SDP body Usting the media as used in the existing session selected for replication; and 

3. application/vnd.3gpp.replication+xml MIME body which optionally can include the playback state. 

21 .3.2.2 SC UE not participating in tlie session to be replicated 
21 .3.2.2.1 Handling push mode session replication request 

Upon receiving a SIP REFER request containing: 

1 . Refer-To header field containing a URI with method parameter equal to "INVITE" or without method parameter; 
and 

2. application/vnd.3gpp.replication+xml MIME body, 

NOTE: the application/vnd.3gpp.replication+xml MIME body can contain the playback state, 
the SC UE: 

1. shaU handle the SIP REFER request as specified in 3GPP TS 24.229 [7] and IETF RFC 3515 [32]. 

21.3.3 sec AS 

21 .3.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following SIP requests to provide specific functionaUty related to session 
repUcation: 

1 . SIP REFER request routed to the SCC AS due to the originating filter criteria containing: 

A. Refer-To header field with a SIP URI with method parameter set to "INVITE" or without method parameter; 
and 

B. application/vnd.3gpp.repUcation+xml MIME body. 

In the procedures below, such request is known as "SIP REFER request due to session replication". 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [7]. 

21 .3.3.2 Session replication from the served UE 

Upon receiving a SIP REFER request due to session rephcation, the SCC AS shall: 
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1. if not authorized, reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining 

steps; and 

2. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [7]. 



22 Roles for collaborative session handling upon loss of 
collaborative session control 

22.1 Introduction 

This clause specifies the roles of controller UE, controller capable UE and the SCC AS when collaborative session 
control is lost and collaborative session control is transferred to another UE. 

22.2 SC UE 

22.2.1 Controller UE 

The user may send or modify controller loss preference at any time during a session using XCAP over Ut interface. 
Candidate UEs in controller loss preference should be configured in a priority order. 

NOTE: The controller UE can support the session timer mechanism as specified in IETF RFC 4028 [37] and 
3GPP TS 24.229 [7J in order to aid the SCC AS detection of loss of collaborative session control. 

22.2.2 Controller capable UE 

There are no additional procedures for the controller capable UE over those specified in subclause 18.2.2. 

22.3 SCC AS 

22.3.1 Session handling upon controller loss 

The following means may be used by to the SCC AS to detect of loss of collaborative session control: 

1) the SCC AS receives a BYE message with a reason header 503 (Service Unavailable) response code; 

NOTE: Since the SCC AS inserted itself in record-route header in lUT scenario, when radio/bearer resources are 
no longer available or the signalling bearer is lost to the UE for a session (e.g. abort session request from 
PCRF) (as specified in 18.229 [9] subclause 5.2.8.1.2), the SCC AS wiU receive a BYE message with a 
reason header 503 (Service Unavailable) response code. 

2) the SCC AS detects a session timeout using the mechanism specified in IETF RFC 4028 [37] and 

3GPPTS 24.229 [7]. 

3) the SCC AS receives a 5xx response for a subsequent request sent to the controller UE. 

Upon detection of a loss of collaborative session control using one of the above mechanisms the SCC AS checks 
controller loss preference in the lUT user preferences (see annex C.3). If the <controller loss preferences> element is 
present, the SCC AS obtains the list of controller capable UEs in the <controller> elements to assume the controller UE 
role. 

NOTE: The SCC AS can use subscription information to determine whether to enable selection of a new 
controller UE based on controller loss preference. 

The SCC AS invites in turn according to the priority order of the <controller> elements in the <controller loss 
preference> each controller capable UE to become a controller of the collaborative session using the following 
procedure: 
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1) The sec AS shall send a SIP INVITE request or SIP re-INVITE request to the UE identified by the SIP URI in 

the <controller> element, containing: 

a) Request-URI with SIP URI from the <controller> element; 

b) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

c) the Content-Type header field set to the value of "multipart/mixed"; and 
f) a "multipart/mixed" MIME body containing the following MIME parts: 

A) the SDP information for the media component to be transferred with the Content-Type set to 
"application/sdp" along with SDP for the media type for each of the media (m=) lines in the session set as 
follows: 

- media Unes for media on other UEs other than UE that control is being transferred to with the port 
number set to zero 

media line(s) for media on the UE that is requested to become a controller of the collaborative session 
containing the port numbers of the remote UE; 

B) containing the Content-Type set to " application/vnd.3gpp.iutH-xml " along with the handling parameter 
set to optional and the XML specified in annex C.2 containing a <controlTransfer> element containing a 
<targetControlIer> element containing the SIP URI from the <controller> element; 

2) If the SIP final response was a non 2xx response or if the Contact header field from the received SIP 2xx 
response does not contain the media feature tag g.3gpp current-iut-controller set to "active" then the SCC AS 
shall repeats the above procedme for the next controller capable UE in the list of <controller> elements in the 
<controUer loss preference>. 

3) Upon receiving a final response to the SIP INVITE request or SIP re-INVITE request which was sent towards 
the controller capable UE, the SCC AS shall: 

a) send a SIP ACK request to the controller UE that sent the final response; 

b) if the Contact header field from the received SIP 2xx response contains the media feature tag g.3gpp current- 
iut-controller set to "active" then consider the UE that sent the SIP 2xx response as the controller of the 
collaborative session. 

4) If no suitable candidate controller capable UEs are left in the hst of <controller> elements in the <controller loss 
preference>, then the SCC AS shall send SIP BYE request to all UEs participating in the session. 



23 Roles for collaborative session media modification 

23.1 Introduction 

This clause specifies the procedures for collaborative session media modification including controller UE initiated 
media modification on controllee UE and controUee UE initiated media modification on itself. 

23.2 Controller UE initiated media modification on controllee UE 
23.2.1 Controller UE 

The controller UE procedures for modifying media on controllee UE by the controller UE is the same as the procedure 
described in subclause 11.2.2.1 with exception that the controller UE additionally sets the port numbers for the media 
types of the media components (in the hname "body" URI header field in the SIP URI in the Refer-To header field of 
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the SIP REFER request) which are being modified on the controllee UE to values from the corresponding media lines 
received dmng the last successful SDP offer and answer exchange with the remote party. 

23.2.2 sec AS serving for collaborative session 

The sec AS procedures for modifying media on controllee UE by the controller UE is the same as the procedure 
described in subclause 11.3.3. 

23.3 Controllee UE initiated media modification on itself 

23.3.1 Controllee UE 

If the controllee UE wants to modify the characteristics of a media component on itself within a collaborative session, 
the controllee UE shall follow the procedures defined in 3GPP TS 24.229 [7] for modifying media. 

23.3.2 sec AS serving the collaborative session 

When sec AS receives a SIP re-INVITE request within an existing dialog from the controllee UE to modify a media 
component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE. The SCC AS shall construct the 
SDP information in the SIP re-INVITE request as follows: 

1) set the media information of the media established in the controllee UE as the same in the SIP re-INVITE 
request received from the controllee UE; and 

2) include the SDP information for all other media components in the collaborative session as received during the 
last successful SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; and 

2) a SIP 200 (OK) response to the controllee UE with an SDP answer that only contains the media component on 
the controllee UE. 



24 Inter-UE transfer and MMTEL interactions 



24.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for inter-UE transfer when execution of supplementary 
service as described in 3GPP TS 22.173 [2]. 

24.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for OIP besides the procedures described in 
3GPPTS 24.607 [13]. 

24.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for OIR besides the procedures described in 
3GPPTS 24.607 LI 3]. 
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24.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.608 [14]. 

24.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.608 [14]. 

24.6 Communication Diversion (CDIV) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.604 [10]. 

24.7 Communication Hold (HOLD) 

The controller UE may hold an active media component(s) on itself, by following the procedures for HOLD described 
in 3GPPTS 24.610 [15]. 

The controller UE may hold or resume an active media component(s) on a controllee UE within a collaborative session 
while it has an ongoing IMS session with a remote UE, by sending a SIP REFER request and including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controUee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) Unes in the session shall be set as follows: 

- media hnes for those media components that are not terminated on the controllee UE with port number 
zero; 

- media lines for those media components that are terminated on the controllee UE and are not to be 
changed with their current directionality and the current port number from the remote end; and 

- media hnes for those media components that are terminated on the controllee UE and: 

if those media components are to be held, set a-line to inactive or recvonly and the current port 
number from the remote end; or 

- if those media components are to be resumed, set a-line to sendonly or sendrecv and the current port 
number from the remote end. 

3) the Accept header field set to "message/sipfrag"; and 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of 
the collaborative session; and 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex B. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPPTS 24.229 [7]. 

When SCC AS receives a SIP REFER request from the controller UE to hold or resume a media component on a 
controllee UE, the SCC AS shall send: 
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1) a SIP 202 (Accepted) response for the SIP REFER request to the controller UE; 

2) a SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and 

3) send a SIP re- INVITE request to the controUee UE, containing: 

a) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of IETF RFC 3892 [36]; and 

b) an SDP offer as received from remote UE in the previous offer/answer exchanged and with directionality as 
set for the corresponding media types in the hname "body" URI header field from the SIP URI in the Refer- 
To header field of the SIP REFER request received from the controller. 

Upon receiving SIP 200 (OK) response from the controUee UE, the SCC AC shall send: 

1) a SIP NOTIFY request to the controller UE with the sipfrag body including the SIP 200 (OK) response of the 
SIP re-INVITE request and also include the SDP information received from the controUee UE. 

2) a SIP re-INVITE request to the remote leg as specified in 3GPP TS 24.229 [7]. The SCC AS shaU construct the 
SDP information in the SIP re-INVITE request as follows: 

- set the SDP information including the directionaUty as received in the SIP 200 (OK) response from the 
controlee UE; and 

include the SDP information for all other media components in the coUaborative session as from the original 

session to the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send a SIP ACK 
request to the remote leg; 

When a controUee UE receives a SIP re-lNVlTE request to hold a media component(s), it shall follow the procedures 
described in 3GPP TS 24.610 [15]. 

24.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for CB besides the procedures described in 
3GPPTS 24.611 [16]. 

24.9 IVIessage Waiting Indication (IVIWI) 

There are no specific procedures for the SC UE and the SCC AS for MWI besides the procedures described in 
3GPPTS 24.606 [12]. 

24.10 Conference (CONF) 

In a collaborative session, it shall only be possible for the controller UE to invoke the CONF service foUowing the 
procedures as described in 3GPP TS 24.605 [1 1]. 

The controller UE of an existing collaborative session may be invited by the remote party or the conference AS to a 
conference using SIP REFER request. In this case, upon receiving a SIP REFER request from the remote party or the 
conference AS, the controller UE performs the same procedures as specified in subclause 24.11.2, and the SCC AS 

perfoms the same procedures as specified in subclause 24.1 1.3. 

NOTE: The SIP URI in the Refer-To header field of the SIP REFER request received by the SCC AS is the 
conference URI, of which the SCC AS may not be aware. However, this does not affect the SCC AS 
procedures. 

The controller UE may be invited by the conference AS to a conference using SIP INVITE request. In this case, upon 
receiving the SIP INVITE request from the conference AS, the controller UE and the SCC AS may perform the 
procedures as described in subclause 17.3 to establish a collaborative session with the conference AS. If there is an 
existing coUaborative session between with the controUer UE and the remote party, and the SIP INVITE request 
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indicates the collaborative session is to be replaced by the new session, the procedures as described in subclause 17.3 
can be performed with the following difference: 

- instead of sending a SIP INVITE request toward the controllee UE to establish a new access leg, the SCC AS 
may send a SIP re-INVITE request towards the controllee UE using the existing access leg between the 
controllee UE and the SCC AS, to update the SDP information over the access leg which has been boimd to the 
new collaborative session. 



In a collaborative session, it shall only be possible for the controller UE to invoke ECT service following the procedures 
as described in 3GPP TS 24.629 [17]. 

When the controller UE receives a notification that ECT has been performed successfully, the controller UE shall 
terminate the previous active session with the transferee UE by terminating all related media control sessions on the 
controllee UEs. 

When the SCC AS receives an ECT transfer request from the remote end to transfer the collaborative session, the SCC 
AS shall deUver the request to the controller UE. 

When the controller UE receives an ECT transfer request to transfer the collaborative session, if the controller UE 
decides not to continue using a collaborative session to communicate with the new remote party (i.e. transfer target), the 
controller UE shall establish a new session towards the transfer target following the procedures described in 
3GPPTS 24.629 [17]. 



As the transferor of the ECT service, only the controller UE can invoke the ECT service on behalf of the collaborative 
session and it shall send a SIP REFER request to the transferee as specified in TS 24.629 [25]. Upon receiving 
notification that ECT has been performed successfully, the controller UE shall terminate the previous active session 
with the transferee UE by terminating all related media control sessions on the controllee UEs. 

Upon receiving a SIP REFER request within an existing collaborative session containing: 

1) the Referred-By header field set to the URI of the remote party; and 

2) the Refer-To header field containing the "method" URI parameter set to INVITE or not including the "method" 
URI parameter, 

the controller UE, if decides to continue using a collaborative session to communicate with the new remote party (i.e. 
transfer target), may send to the SCC AS a SIP INVITE request including: 

1) the Request-URI set to the URI in the Refer-To header field of the SIP REFER request; and 

2) the SDP information as follows: 

- for the media component(s) that are to be established in the controller UE, containing the port number(s) of 
the controller UE; and 

for the media component(s) that are to be established in the controllee UE, containing the 
"a=3gpp.iut.controllee" attribute set to the same SIP URI of controllee UE as in the original collaborative 
session. 

The following procedures of the controller UE for establishing the collaborative session with the transfer target is the 
same as described in subclause 17.2.1. 



24.1 1 Explicit Communication Transfer (ECT) 



24.11.1 



General 



24.11.2 SCUE 
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24.11.3 sec AS 

Upon receiving from the remote party a SIP REFER request in the existing dialog for which a collaborative session is 
established in the local party, the SCC AS shall forward the SIP REFER request towards the controller UE using the 

procedures as specified in TS 24.229 [9]. 

Upon receiving a SIP INVITE request from the controller UE due to the SIP REFER request and the SIP INVITE 
request includes: 

1) the Request-URI set to the URl in the Refer-To header field of the SIP REFER request; and 

2) the SDP information as follows: 

- for the media component(s) that are to be estabhshed on the controller UE containing the port number(s) of 
the controller UE; and 

- for the media component(s) that are to be established in the controllee UE, containing the 
"a=3gpp.iut.controUee" attribute set to the same SIP URI of controllee UE as in the original collaborative 
session, 

and if required by local policy, the SCC AS shall establish a new collaborative session towards the new remote party 
(i.e. transfer target), using the procedure as described in subclause 17.2.2 with the following difference: 

- instead of sending a SIP INVITE request toward the controllee UE to establish a new access leg, the SCC AS 
may send a SIP re-INVITE request towards the controllee UE using the existing access leg between the 
controllee UE and the SCC AS, to update the SDP information over the access leg which has been boimd to the 

new collaborative session. 

NOTE 1 : The SCC AS can not distinguish the SIP REFER request for ECT from the common SIP REFER request. 
However this does not affect the SCC AS procedures, i.e. the SCC AS can decide, based on the SIP 
INVITE request from the controller UE due to the SIP REFER request, to reuse the existing access leg of 
the controllee UE for the new collaborative session. 

NOTE 2: The SCC AS can decide the duration that it keeps the information of the SIP REFER request based on, 
e.g. the expiration time of the SIP REFER request (the Expires header field in the REFER request) and 
the duration of the implicit subscription created by the SIP REFER request ('expires' header field 
parameter in the Subscription-State header field in the first NOTIFY sent in the subscription) as specified 
in IETF RFC 35 15 [5], so that the SIP INVITE request from controller UE can be associated with the SIP 
REFER request. 

24. 1 2 Advice of Charge (AOC) 

When the AOC service specified in 3GPP TS 24.647 [23] is active, the SCC AS shall deliver charging information to 
the controller UE. 

24. 1 3 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for CUG besides the procedures described in 
3GPPTS 24.654 [24]. 

24.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONE service in 3GPP TS 24.605 [11] and the interaction with 
inter-UE transfer is the same as that specified in subclause 24.2.10 for CONF service. 

24.15 Flexible Alerting (FA) 

There are no specific procedures for the SC UE and the SCC AS for FA besides the procedures described in 
3GPPTS 24.239 [18]. 
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24.16 Communication Waiting (CW) 

There are no specific procedures for the SC UE and the SCC AS for CW besides the procedures described in 
3GPPTS 24.615 [20]. 

24.17 Completion of Communications to Busy Subscriber 
(CCBSyCompletion of Communications by No Reply 
(CCNR) 

There are no specific procedures for the SC UE and the SCC AS for CCBS/CCNR besides the procedures described in 
3GPPTS 24.642 [22]. 



24. 1 8 Customized Alerting Tones (CAT) 

For Collaborative Sessions established concurrently with terminating IMS session setup, the CAT provided by the 
network (under the control of the SCC AS associated with the controller UE) to the remote party is the CAT associated 
with the controller UE. 

24.19 Malicious Communication IDentification (MCID) 

There are no specific procedures for the SC UE and the SCC AS for MCID besides the procedures described in 
3GPPTS 24.616 [21]. 



24.20 Personal Network Management (PNM) 

There are no specific procedures for the SC UE and the SCC AS for PNM besides the procedures described in 
3GPPTS 24.259 [19]. 



24.21 Customized Ringing Signal (CRS) 

For Collaborative Sessions established concurrently with terminating IMS session setup, the Customized Ringing 
Signal (CRS) provided to the controller UE is the CRS associated with the remote party. For Collaborative Sessions 
estabhshed concurrently with originating IMS session setup, the CRS provided to the remote party is the CRS 
associated with the controller UE. 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for inter-UE transfer based on the Session Initiation Protocol (SIP) and 

SIP Events. 

These signalhng flows provide detailed signalhng flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [4]. 

A.2 Introduction 
A.2.1 General 

The signalhng flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [6]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [6] subclauses 4.1 and 4.2 applies with the additions 
specified below: 

- tel:+l-237-555-llll represents the public user indentity of SC UE A. 

- tel:+l-237-555-2222 represents the public user indentity of UE B. 

- sip:sccasl.homel.net represents the Internet host of SCC AS. 

sip:interUEtransfer@sccasl .homel .net represents the Inter UE Transfer SCC AS URI of the UA A. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [6]. 

However, 3GPP TS 24.228 [6] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [6], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [6] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 
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INVITE 



SETUP 



-► SIP message 
CS message 

Media over a PS connection 
Media over a CS connection 



Figure A.2-1 : Signalling flow notation 



A.3 Signalling flows for Inter-UE Transfer without 
establishment of Collaborative Session 

A.3.1 Introduction 

The signalling flows in the subclause demonstrate how an SC UE can initiate the inter UE transfer of the complete 
session without Collaborative Session establishment. 

The example assumes that the UE-1 and UE-2 are under the control of the same subscriber. 

A.3. 2 Complete transfer in services defining only originating 
session set up in UE 

In the example flow at the figure A. 3. 2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS. 
The session is established using an IMS communication service identified by ICSl urn:urn-7:3gpp-service.ims.icsi.iptv 
which is an IMS communication service which defines originating session set up in the UE only. 
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Figure A.3.2-1 : Signalling flow for inter UE transfer without Collaborative Session 

establishment 

NOTE 1: For clarity, the SIP 100 (Trying) responses and the SIP NOTIFY requests earring the message/sipfrag 
with SIP 100 (Trying) response are not shown in the signalling flow. 



1. UE-1 is in session witli UE-3 
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There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS. The session was estabhshed using IMS communication service identified by ICSI urniiu'n- 
7:3gpp-service.ims.icsi.iptv. The dialog identifier of the session is AB03a0s09a2sdfglkj490333, remote- 
tag=Afgsdfg45, local-tag=U188gg. 

2, SIP REFER request initiating the inter UE transfer to UE-2 (UE-1 to Intermediate IM CN subsystem 
entities) - see example in table A.3.2-2 

Table A.3.2-2: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities) 

REFER sip :User@homel . net ; gr=urn : uuid : f 8 ld4fae-7dec- Ild0-a76 5 -222222222222 SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 
From : <sip : userohomel . net > ; tag=17182 8 

To : <sip : userohomel .net ;gr=urn:uuid: f81d4fae-7dec-lld0-a765-222222222222> 
Call-ID: Asdasd231233 
Cseq: 4127 REFER 

Contact : <sip : userohomel . net ; gr=gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765-llllllllllll> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Length: 

Refer-To : <sip : interUEtransf erOsccas . homel . net?Target- 

Dialog=AB03a0s09a2sdfglkj490333%3Bremote-tag=Afgsdfg45%3Blocal- 

tag=U188gg&Require=tdialog&P-Preferred-Service=urn:urn-7 : 3gpp-service . ims . icsi . iptvSiAccept- 
Contact = * %3b+g . 3gpp . icsi -ref %3d%22urn%253Aurn-7%253gpp-service . ims . icsi . iptv%22> 
Referred-By: sip :user@homel . net 



Request-URI: contains the GRUU of the UE-2 

Refer-To: contains the Inter UE Transfer SCC AS URItogether with Target-Dialog URI header field 
containing the dialog identifier of the session with UE-3, Require URI header field containing the "tdialog" and 
P-Preferred-Service and Accept-Contact URI header fields containing the ICSI of the service to be requested by 
UE-2. 

Contact: contains the GRUU of the UE-1 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP REFER 

request towards the SCC AS. 

4. SIP REFER request (Intermediate IM CN subsystem entities to SCC AS) 

5. The SCC AS authorizes the request and if authorization is passed successfully, the SCC AS forwards the 
SIP REFER request further 

6. -7. SIP REFER request (SCC AS to UE-2) 

8.-11. SIP 202 (Accepted) response to the SIP REFER request (UE-2 to UE-1) 

12. SIP INVITE request (UE-2 to intermediate IM CN subsystem entities) - see example in table A.3.2-12 
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Table A.3.2-12: SIP INVITE request (UE-1 to Intermediate IM CN subsystem entities) 



INVITE sip : interUEtransf erOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 

From : <sip : userohomel . net > ; tag=17182 8 

To : <sip : interUEtransf erOsccas . homel . net> 

Call-ID: tq34gasgaegr 

Cseq: 4127 INVITE 

Contact : <sip : userohomel . net ;gr=urn : uuid : f 8 ld4fae-7dec- lldO-a7S 5 -222222222222 > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Target-Dialog: AB03a0s09a2sdf glkj490333 ; remote -tag=Afgsdfg4 5 ; local-tag=U188gg 

Require: tdialog 

Content-Type: application/sdp 

Content-Length: (...) 

Supported: lOOrel, precondition 

P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . iptv 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . iptv" 
Referred-By: sip :user@homel . net 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 

s = 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 

m=video 34 00 RTP/AVP 98 99 

b=AS : 75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: set to the URI in the Refer-To of the received SIP REFER request 
Contact: contains the GRUU of the UE-2 

Target-Dialog: set to the value of the Target-Dialog URI header field of the URI in the Refer-To of the 
received SIP REFER request 

Require: set to the value of the Require URI header field of the URI in the Refer-To of the received SIP 

REFER request 

P-Preferred-Service: set to the value of the P-Preferred-Service URI header field of the URI in the Refer-To 

of the received SIP REFER request 

Accept-Contact: set to the value of the Accept-Contact URI header field of the URI in the Refer-To of the 
received SIP REFER request 

13. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP INVITE 
request towards the SCC AS. 

14. SIP EWITE request (Intermediate IM CN subsystem entities to SCC AS) 

15. Remote Leg Update 
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Based on the STI in the Target-Dialog header field the SCC AS detects that the inter UE tranfer is being 
attempted and performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

16-18. SIP re-INVITE request (SCC AS to UE-3 over intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE-3 via the 
intermediate IM CN subsystem entities. 

19-21. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

22-24. SIP ACK request (SCC AS to UE-3 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE-3. 

25-26. SIP 200 (OK) response (SCC AS to UE-2 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwai'ds the SIP 200 (OK) 
response towards the UE-2. 

27-28. SIP ACK request (UE-2 to SCC AS via intermediate IM CN subsystem entities) 

The UE-2 generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS. 

29. Media and IMS service control paths: 

The media path is now established between UE-2 and UE-3 and the IMS service control between UE-2 and SCC 
AS. 

30-33. SIP NOTIFY request (UE-2 to UE-1 over intermediate IM CN subsystem entities and SCC AS) 

The UE-2 generate the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-1. 

34-37. SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem 
entities and SCC AS) 

38-39: SIP BYE request (SCC AS to UE-1 via intermediate IM CN subsystem entities) 

The SCC AS terminates the source access leg by sending a BYE request to the UE-1. 

40-41. SIP 200 (OK) response (UE-1 to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request, the UE-1 sends a SIP 200 (OK) response to the SCC AS. Subsequently, 
the UE-1 relinquishes all resources pertaining to the session. 

A.3.3 Complete transfer in services defining terminating session 
set up in UE 

Editor's note: Complete transfer in services defining terminating session set up in UE is FFS 

A.3.4 Inter UE transfer triggered by SC UE not participating in the 
session to be transferred 

In the example flow at the figure A. 3. 4-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. 
UE-1 and UE-2 belong to the same IMS subscriptions. The SCC AS-1 authorizes the inter UE transfer request on behalf 
of the UE-1. 
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HPLMN of the local UE participating in session and of the UE transferring the session 



HPLMN of the application server acting as 
terminating UE {UE-3) participating in 

session 



I UE-1 



sec AS-1 



UE-2 



IMS session control 



Intermediate IM CN subsvtem 
entitities 



2. Media patli 



Intermediate IIVI CN subsvtem 
entitities 



UE-3 



3. UE-2 discovers the 
sessions of UE-1 



6. re-INVITE 



11.200OKtore-INVITE 
12. ACK 



15. 200 OK to INVITE 



16. 200 OK to INVITE 



17. ACK 



18. ACK 



19. BYE 



20. BYE 



21. 200 OK to BYE 



22. 200 OK to BYE 



23. IMS session control 



7. re-INVITE 



10. 200 OK to re-INVITE 



13. ACK 



24. Media path 



8. re-INVITE 



9. 200 OK to re-INVITE 



14. ACK 



Figure A.3.4-1 : Signalling flow for inter UE transfer without collaborative session establishment 

triggered by UE not participating in the session 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 

1-2. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS-1. The dialog identifier of the session between SCC AS-1 and UE-1 is 
AB03a0s09a2sdfglkj490333, remote-tag=dfg45, local-tag=444. 

3. UE-2 discovers the sessions of UE-1 as shown in subclause A.23 

4-5. SIP EWITE request (UE-2 to SCC AS-1) - see example in table A.3.4-4 

The UE-2 sends SIP INVITE request to transfer the session to the UE-2. 
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INVITE sip : interUEtransf erOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : user2@homel . net > 
From : <sip : user2@homel . net > ; tag=17182 8 
To : <sip : interUEtransf erOsccas . homel . net> 
Call-ID: tq34gasgaegr 
Cseq: 4127 INVITE 

Contact : <sip : user2@homel . net ;gr=urn : uuid : f 8 Id4fae-7dec-lld0 -2222 -222222222222 >; +g . Sgpp . icsi- 
ref = "urn%3Aurn- 7%3A3gpp-service . ims . icsi . iptv" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Replaces : ABO 3a0 s 9a2sdfglkj 4 90333 ; remote- tag=dfg4 5 ; local -tag=444 
Require: replaces 
Content-Type: application/sdp 
Content-Length: (...) 

Supported: lOOrel, precondition, 199 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 

s= 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 

m=video 34 00 RTP/AVP 98 99 

b=AS : 75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: contains the Inter UE Transfer SCC AS URI 

Replaces: set to the dialog information of the session to be transferred 

6.-8. SIP re-EVVITE request (SCC AS-1 to UE3) 

Since the request is addressed to SCC AS-1 and since STI in the Replaces header field identifies an dialog 
anchored in the SCC AS-1, the SCC AS-1 detects that the inter UE transfer is being attempted, authorizes the 
request of behalf of UE-1, acts as a routing B2BUA and performs remote leg update by sending the SIP re- 
INVITE request towards the UE-3. 

9-11. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

12-14. SIP ACK request (SCC AS-1 to UE-3 via intermediate IM CN subsystem entities) 

The SCC AS-1 generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE-3. 

15-16. SIP 200 (OK) response (SCC AS-1 to UE-2 via intermediate EM CN subsystem entities) 

The SCC AS-1 generates the SIP 200 (OK) response to the SIP EWITE request, and forwards the SIP 200 (OK) 
response towards the UE-2. 
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17-18. SIP ACK request (UE-2 to SCC AS-1 via intermediate IM CN subsystem entities) 

The UE-2 generates the SIP ACK request to the SIP 200 (OK) response. 
19-20. SIP BYE request (SCC AS-1 to UE-1 via intermediate EM CN subsystem entities) 

The SCC AS-1 terminates the source access leg by sending a BYE request to the UE-1. 

21-22. SIP 200 (OK) response (UE-1 to SCC AS-1 via intermediate IM CN subsystem entities) 

Upon receiving the BYE request, the UE-1 sends a SIP 200 (OK) response. Subsequently, the UE-1 releases all 
resources pertaining to the session. 

23-24. UE-2 is now in session with UE-3 

A.4 Signalling flows for establishment of collaborative 
session for inter-UE transfer 

A.4.1 Introduction 

This clause describes signalhng flows for estabhshing a collaborative session. Two different scenarios have been 
considered: 

subclause A.4. 3 shows an example where the collaborative session is estabhshed by transferring a media 
component from the controller UE to a controllee UE; and 

- subclause A.4. 3 and shows an example where the collaborative session is established by adding a new media 
component on a controllee UE. 
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A.4.2 Collaborative session establishment with media transfer 



UE-1 



UE-2 



IMS CN 



sec AS 



Remote 
UE 



-(Audio, Video)- 



-1. REFER- 



I 

-4. 202 ACCEPTED- 



I 

-6. NOTIFY- 

I 

-7. 200 OK- 



-10. INVITE- 



-11. 200 OK- 
—14. ACK— 



-16. re-INVITE- 

I 

—17. 200 OK— 
I 

20. ACK 



-28. re-INVITE- 
I 

—29. 200 OK— 
I 

32. ACK 



-34. re-INVITE- 
—35. 200 OK— 
38. ACK 



-40. NOTIFY- 



I 

-41. 200 OK- 



-2. REFER- 



-3. 202 ACCEPTED- 

5. NOTIFY 

8. 200 OK 

9. INVITE 



-12. 200 OK- 
—13. ACK — 



-15. re-INVITE- 
—18. 200 OK— 
19. ACK 



-21. re-INVITE- 



-24. 200 OK- 
—25. ACK — 



-27. re-INVITE- 
—30. 200 OK— 
31. ACK 



-33. re-INVITE- 
—36. 200 OK— 
37. ACK 



-39. NOTIFY- 
-42. 200 OK- 



■(Audio)- 



-22. re-INVITE- 



I 

-23. 200 OK- 



-(Video)- 



-26. ACK- 



Figure A.4.2: Controller UE establishes a cllaborative session by transferring a media 

from controller UE to controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio and video between controller UE, UE-1 (123.45.67.89), and remote UE 
(132.54.76.98). The video component is bidirectional from the remote UE to the controller UE, UE-1. The 
Controller UE attempts to transfer the video portion of this session to the controUee UE, UE-2. 
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Table A.4.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip: interUEtransferSsccasl .homel .net SIP/2.0 
Via : 

To : sip : interUEtransf erOsccasl . homel . net 

From: sip : userl_publicl®homel . net ; tag=13579 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Ref er-To : <sip : userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5-00a0c91e6bf 6?body= 

m%3Daudio%2 00%2 0RTP%2FAVP%97%0Dm%3Dvideo%2 03 002%2 0RTP%2FAVP%2 098%2 099> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 321576 ; remote- tag=abcdef ; local -tag=1234 56 
Contact : <sip : userlpubliciohomel . net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz> ; +g . 3gpp . iut -controller 
Ref erred-By : sip : userl_publicl@homel . net 
Accept: application/sdp, message/sipf rag 
Content -Length: 



3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to controller UE-1 to notify impUcit subscription to the SIP REFER 
request results. 

Table A.4.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To: sip : user l_publicl@homel .net ; tag=24 680 

From: sip : interUEtransf er@sccasl . homel .net ; tag=13579 

Call-ID: Cb03a0s09a2sdfglkj490333 

CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- State : active;expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP INVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP INVITE request to the controUee UE, UE-2, to transfer video media. 
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Table A.4.2-9 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip:userl j)ublic2@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

To : sip : userl_public2®homel . net ; 

From: sip : interUEtransf erOsccasl . homel . net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Ref erred-By : sip :userl_publicl®homel . net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendonly 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.4.2-11 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via: 




To: sip:userl public2@homel.net; 


tag = 27365 


From: sip : interUEtransf erOsccasl 


homel.net; tag = 36527 


Call-ID: Cb03a0s09a2sdfglkj22222 




CSeq: 




P- Preferred- Identity : 




Contact: sip : userl_public2®homel 


net ;gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145 . 23.77. 88 


s = - 

c=145 .23.77.88 




t = 




m=audio RTP/AVP 97 




m=video 1302 RTP/AVP 98 99 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




a= inactive 





13-14. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to the controUee UE, UE-2. 

15-16. SIP re-INVITE request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP re-INVITE request to the controller UE, UE-1. 
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Table A.4.2-15 SIP INVITE request (SCC-AS to UE-1) 



INVITE sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via : 

To : sip : userl_publicl®homel . net ; tag=11928 
From: sip :user3_public3@home3 . net ; tag = 27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 3 02 RTP/AVP 98 99 

a=sendonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



17-18. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP re- INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 

Table A.4.2-17 SIP 200 (OK) response (UE-1 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To: sip : user3_public3@home3 . net ; tag = 27364 
From : sip : userl_publicl@homel . net ; tag=1192 8 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

P -Preferred- Identity : 

Contact : sip : user l_public2@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 

Allow: 

Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 

s=- 

c=145 .23.77.88 
t = 

m=audio 1300 RTP/AVP 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=video 1302 RTP/AVP 98 99 
b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a= inactive 



19-20. SIP ACK request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP ACK request to the controllel UE, UE-1, in response to the SIP 200 (OK) response. 
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21-22. SIP re-EWITE request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP re-INVITE request to the remote UE. 

Table A.4.2-21 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip:user3_public3@home3 .net SIP/2.0 
Via: 

To: sip :user3_public3®home3 . net ; tag = 11928 
From: sip :userl_publicl@homel .net ; tag=27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : user l_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 
t=0 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123.45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=video 1302 RTP/AVP 98 99 
C=IN IP4 145.23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23-24, SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 

Table A.4.2-23 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 
Via: 

To: sip :userl_publicl®homel . net ; tag=27364 
From: sip :user3 j)ublic3@home3 . net ; tag = 11928 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_public3@home3 . net 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 
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25-26. SIP ACK request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 
27-28. SIP re-INVITE request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP re-INVITE request to the controller UE, UE-1. 

Table A.4.2-27 SIP INVITE request (SCC-AS to UE-1) 



INVITE s ip: user IpubliclOhomel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To : sip :userl_publicl®homel . net ; tag=11928 
From: sip : user3 j>ublic3@home3 . net ; tag = 27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 96 97 

b=AS:25.4 

a= r tpmap : 9 6 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video RTP/AVP 98 99 



29-30. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 

Table A.4.2-29 SIP 200 (OK) response (UE-1 to SCC-AS) 



SIP/2.0 200 OK 
Via: 

To: sip:user3j)ublic3@home3 .net;tag = 27364 
From: sip : user l_publicl@homel .net ; tag=1192 8 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

P- Preferred- Identity : 

Contact : sip:userl j)ublic2@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s=- 

c=145.23.77.88 
t = 

m=audio 1300 RTP/AVP 97 

b=AS:25.4 

a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video RTP/AVP 98 99 



31-32. SIP ACK request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP ACK request to the controUel UE, UE-1, in response to the SIP 200 (OK) response. 
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33-34. SIP re-EWITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP re-INVITE request to UE-2 to activate the video media components. 

Table A.4.2-33 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip : user l_public2®homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip :userl_public2®homel . net ; 

From: sip : interUEtransf erOsccasl . homel .net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Ref erred-By: sip:userl_publicl@homel .net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

c=IN IP4 132 . 54 . 76 . 98 

t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendrecv 



35-36. SEP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.4.2-35 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip:userl public2@homel.net; 


tag = 27365 


From: sip : interUEtransf erOsccasl 


homel.net; tag = 3652 7 


Call-ID: Cb03a0s09a2sdfglkj22222 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl_public2@homel 


net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145.23.77.88 


s=- 

c=145.23.77.88 




t = 




m=audio RTP/AVP 97 




m=video 1302 RTP/AVP 98 99 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




a=sendrecv 





37-38. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to the controllee UE, UE2. 
39-40. SIP NOTIFY request (from SCC-AS to UE-1) 
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The SCC-AS sends a SIP NOTIFY request to controller UE, UE-1, to inform about the success status of the 
inter-UE transfer. 

Table A.4.2-39 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To: sip :userl_publicl@homel . net ; tag=24680 

From: sip: interUEtransf er@sccasl .homel .net ; tag=13579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ;version=2.0 
Content -Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 
v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 

s=- 

c=145.23.77.88 

t = 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendrecv 



41-42. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 



A.4.3 Collaborative session establishment with new media 

There is an existing session with audio between controller UE, UE-1, and the remote UE. The controller UE estabUshes 
a collaborative session by adding a video media component to the controllee UE, UE-2. 



ETSI 



3GPP TS 24.337 version 10.8.0 Release 10 



83 



ETSI TS 124 337 VI 0.8.0 (2013-07) 



UE-1 



UE-2 



IMS CN 



sec AS 



UE- 
remote 



-1. REFER- 



^. 202 ACCEPTED 

6. NOTIFY 

I 

7. 200 OK 



•4 10. INVITE- 

1 1 . 200 OK- 

M 14. ACK 



22 Re-INVITE 

—23. 200 OK— 
26. ACK — 



-28. NOTIFY- 

I 

-29. 200 OK- 



■(Audio)- 



2. REFER 



^3. 202 ACCEPTED 
•4 5. NOTIFY 

8. 200 OK 1 



9. INVITE 



-12. 200 OK- 
— 1 3. ACK— 



15. Re-INVITE 



16. Re-INVITE 

I 

— 1 7. 200 OK— 



-18. 200 OK- 



20. ACK 



21 . Re-INVITE 
24. 200 OK — 
25. ACK 



27. NOTIFY- 

30. 200 OK- 



■(Audio)- 



19. ACK 



-(Video)- 



Figure A.4.3: Controller UE establishes a collaborative session by adding a new media 

on controllee UE 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1-2. SIP REFER request (from UE-1 to SCC-AS) 

The controller UE, UE-1 sends a SIP REFER request to the SCC AS containing a Refer-To header field 
containing the GRUU of controllee UE, UE-2 and a body parameter containing an m hne for audio set to zero 
and an m line for video with the port number set to the discard port number "9" since the port number is 
unknown. The SIP REFER request also includes a Target-dialog header field containing the details of the dialog 
for the existing session between controller UE, UE-1 and the remote UE. 
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Table A.4.3-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip: interUEtransferSsccasl .homel .net SIP/2.0 




Via : 




To : sip : interUEtransf erOsccasl . homel . net 




From: sipiuserl publiclohomel . net ; tag=24680 




Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 




CSeq: 93809824 REFER 




Max-Forwards: 70 




P-Pref erred-Identity : sip:userl publicl@homel.net 




Refer- To : <sip : userl public2®home2 . net ; gr=urn : uuid : f 81d4f ae- Tdec- 


Ild0-a762- 


OOaOcSleSbf 6?body=m%3Daudio%200%20RTP%2FAVP%2096%0Dm%3Dvideo%209%20RTP%2FAVP%2098%2099> 


Require: target-dialog 




Target-dialog: cb03a0s09a2sdfglkj 13579 ; remote-tag=abcdef ; local- 


tag=123456 


Referred-By: sip: userl publicl@homel.net 




Contact : <sip :userl_publicl®homel . net ; gr=urn:uuid: f 81d4f ae-7dec- 


Ild0-a765- 


00a0c91ewxyz>; +g. 3gpp . iut- controller 




Allow: 




Accept: message/sipf rag 




Content-Length: 




3-4, SIP 202 (Accepted) response (from SCC AS to UE-1) 



The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to UE-1 notifying implicit subscription to the SIP REFER request. 



Table A.4.3-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via: 

To : sip : userl_publicl@homel .net ; tag=24 680 

From; sip : interUEtransf erOsccasl . homel .net ; tag=13579 

Call-ID: 

CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- State : active;expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP INVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP INVITE request to the controllee UE, UE-2, adding video media and establishing a 
collaborative session. Since the URI parameters indicate that the port number for the video m-line is set to the 
discard port number "9", the SCC AS realizes that the port number of the remote UE is unknown and therefore 
adds an a-line to inactive in the SDP offer to prevent the controllee UE sending media to the remote UE. The 
SDP offer contains the audio media component on controller UE, UE-1 set to zero. 
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Table A.4.3-9 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip:user2 j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

Record-Route : sip : scc-as@homel .net 

To: sip : user2 jubliclohomel . net ; 

From: sip :user3 j>ublic3@home3 .net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted-Identity : "remote user" sip:user3_public3@home3 .net 

Require : 

Contact : sip :user3_public3@home3 .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 
t=0 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 99 
a=inactive 
c=0 .0.0.0 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



The value of c-line is set to a domain name within the ".invaUd" DNS top-level domain in case of IPv6 as 
described in IETF RFC 6157 [43]. 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2, acknowledges the SIP INVITE request by sena ding SIP 200 (OK) response to the 
SCC-AS. In the following example, the controUee UE which has controller capabilities sends g.3gpp.iut- 
controUer media feature tag in the Contact header field to indicate the support for the controller UE procedures. 

Table A.4.3-11 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via: 

To : sip :user2_publicl®homel . net ; tag=xyzwv 
From: sip :user3 j>ublic3@home3 .net ; tag=acegi 

Call-ID: 
CSeq: 

P- Preferred- Identity : 

Contact : sip : userl_public2@home2 . net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6 ; +g . 3gpp . iut -controller 
Allow: INVITE, PRACK, UPDATE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s=- 

t = 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 
a= inactive 
c=145.23.77.88 
b=AS:75 

a=rtpmap:98 H2 6 3 

a=fmtp:98 prof lie - level - id=0 



13-14. SIP ACK request (from SCC-AS to controUee UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 
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15-16. SIP re-EWITE request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP re-INVITE request to the remote UE. 

Table A.4.3-15 SIP re-INVITE request (SCC-AS to remote UE) 



INVITE sip:user3_public3@home3 . net ; gr=urn :uuid: f 81d4f ae-17oct- Ilal-a678-0054c91eabcd SIP/2 . 
Via: 

To: sip :user3_public3@home3 .net ; tag=66666 
From: sip:userl j)ublicl@homel .net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : userl_publicl@homel .net ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 
t=0 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123.45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video 1302 RTP/AVP 98 

C=IN IP4 145.23.77.88 

b=AS : 75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 



17-18. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 

Table A.4.3-17 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

CSeq: 

P-Asserted- Identity: 

Contact : sip :user3_public3@home3 .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

C=IN IP4 123.112.67.87 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 20 

m=video 3002 RTP/AVP 98 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



19-20. SIP ACK request (from SCC-AS to remote UE) 
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The SCC-AS sends a SIP ACK request to the remote UE. 

21-22. SIP re-EVVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP re-INVITE request to the controllee UE, UE-2 to inform the controUee UE about the 
port number for the video media component of the remote UE. The SCC AS adds an a-line set to active in the 
SDP offer. The SIP INVITE request contains a Referred-By header field containing the identity of UE-1 from 
the Referred-By header field from the SIP REFER request. 

NOTE 1: This SIP re-INVITE request is triggered by the SIP REFER request in steps 1-2. The previous SIP 

INVITE request was generated by the SCC AS due to third party call control to allow sending this SIP re- 
INVITE request. 

NOTE 2: Any other changes such as the IP address of the remote UE in case the remote UE uses different IP 
addresses for different media would also be updated in the SIP re-INVITE request. 

Table A.4.3-21 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip: user l_public2®home2 . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 

Via: 

To: 

From : 

Call-ID: 

CSeq: 

Contact : sip:user3 j)ublic3@home3 .net ;gr=urn:uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Referred-By: sip:userl_publicl@homel .net 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.87 
s=- 

C=IN IP4 123.45.67.87 
t = 

m=audio RTP/AVP 96 97 

m=video 3002 RTP/AVP 98 

b=AS:75 

a=active 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 



23-24. SIP 200 (OK) response (from controUee UE to SCC-AS) 



Table A.4.3-23 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To I 




From : 




Call-ID: 




CSeq: 




Contact: sip:userlj)ublic2@home2 


net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145.23.77.88 


s=- 
t=0 




m=audio RTP/AVP 




m=video 13 02 RTP/AVP 98 




c=145 .23.77.88 




b=AS : 75 




a=active 




a=rtpmap:98 H2S3 




a=fmtp:98 prof ile-level-id=0 





25-26. SIP ACK request (from SCC-AS to controUee UE) 
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The SCC-AS sends a SIP ACK request to the controUee UE to acknowledge. 

27-28. SIP NOTIFY request (from SCC-AS to conroUer UE, UE-1) 

When the media component is added to the controUee UE, UE-2, the SCC-AS sends a SIP NOTIFY request to 
the controller UE, UE-1 to inform about the success status of adding the media to the controUee UE, UE-2. 

Table A.4.3-27 SIP NOTIFY request (SCC-AS to UE-1) 

NOTIFY 
Via: 

To: sip:userl_publicl®homel .net ; tag = 13579 
From: sip : scc-as®homel .net ; tag=24 680 
Call-ID: 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

m=audio RTP/AVP 

m=video 1302 RTP/AVP 98 99 

c=145.23.77.88 

b=AS:75 

a=active 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 



29-30. SIP 200 (OK) response (from controUer UE to SCC-AS) 

The controller UE acknowledges the NOTIFY request by sending a SIP 200 (OK) response to the SCC-AS. 



A.5 Signalling flows for media transfer within 
collaborative session for inter-UE transfer 

A.5.1 Introduction 

This subclause describes signalUng flows for media transfer within collaborative sessions. Two different scenarios are 
considered in the clause: 

subclause A. 5. 2 shows an example where a media component is transferred from the controller UE to the 
controUee UE; and 

- subclause A.5. 3 shows an example where a media component is transferred from one controUee UE to another 
controUee UE. 
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A.5.2 Controller UE initiated media transfer from controller UE to 
controllee UE 
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Figure A.5.2: Controller UE transfers a media on controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audiol and video between the controller UE, UE-1 (123.45.67.89), and the 
remote UE (132.54.76.98). There is another audio2 component between the controllee UE, UE-2 (145.23.77.88), 
and the remote UE. The video component is bidirectional from the remote UE to the controller UE, UE-1. The 
Controller UE attempts to transfer the video portion of this session to the controllee UE, UE-2. 
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Table A.5.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip: interUEtransferSsccasl .homel .net SIP/2.0 
Via : 

To : sip : interUEtransf erOsccasl . homel . net 

From: sip : userl_publicl®homel . net ; tag=13579 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Ref er-To : <sip : userl_public2®homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6 ?body= 
m%3Daudio%2 0%2 0RTP%2FAVP%2 097%0Dm%3Daudio%2 03 004%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 03 002%2 0RTP 
%2FAVP%2 098%2 099> 

Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 321576 ; remote -tag=abcdef ; local-tag=12 34 56 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91ewxyz> ; +g . 3gpp . iut -controller 
Ref erred-By : sip : userl_publicl®homel . net 
Accept: application/sdp, message/sipf rag 
Content-Length: 



3-4, SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.5.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To: sip:userl j>ublicl@homel .net ; tag=24 680 

From: sip : interUEtransf er@sccasl . homel .net ; tag=13579 

Call-ID: 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- State : active; expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP re-INVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP re-INVITE request to the controllee UE, UE-2, to transfer video media. In order to 
avoid UE-2 to start sending video to the remote UE, the SCC-AS adds an a-line set to sendonly and b-lines to set 
the bandwidth to in the SDP offer. 
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Table A.5.2-9 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip:userl j)ublic2@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

To : sip : userl_public2®homel . net ; 

From: sip : interUEtransf erOsccasl . homel . net ; tag=12486 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Ref erred-By : sip :userl_publicl®homel . net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=audio 3004 RTP/AVP 96 97 
a=rtpmap :0 PCMU/8000 
b=RR : 
b=RS : 

m=video 3002 RTP/AVP 98 99 

a=sendonly 

b=RR : 

b=RS : 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.5.2-11 SIP 200 OK response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip :userl_public2@homel . net ; 


tag = xyzwv 


From: sip : interUEtransf er®sccasl 


homel.net; tag = 124 86 


Call-ID: 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl_public2@homel 


net ;gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145 . 23.77. 88 


s = - 

c=145 .23.77.88 




t = 




m=audio RTP/AVP 97 




m=audio 13 04 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




m=video 1302 RTP/AVP 98 99 




a=recvonly 




b=AS:75 




a=rtpmap:98 H2 63 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





13-14. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to the controUee UE, UE-2. 
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15-16. SIP re-EWITE request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP re-INVITE request to the controller UE, UE-1. 

Table A.5.2-15 SIP INVITE request (SCC-AS to UE-1) 



INVITE sip : user l_publicl@homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2.0 
Via: 

To: sip : user l_publicl®homel . net ; tag=1192 8 
From: sip :user3_public3@home3 .net ; tag = 27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 96 97 
m=audio 3000 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=video 3 02 RTP/AVP 98 99 

a=sendonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



17-18, SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 
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Table A.5.2-17 SIP 200 (OK) response (UE-1 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To: sip : user3_public3®home3 . net ; tag = 27364 
From : sip : user IjiubliclOhomel . net ; tag=11928 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

P- Preferred- Identity : 

Contact : sip : userl_public2®homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s = - 

c=145 .23.77.88 
t = 

m=audio RTP/AVP 96 97 
m=audio 1300 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 20 

m=video 1302 RTP/AVP 98 99 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



19-20. SIP ACK request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP ACK request to the controller UE, UE-1, in response to the SIP 200 (OK) response. 
21-22. SIP re-INVITE request (from SCC-AS to remote UE) 
The SCC-AS sends a SIP re-INVITE request to the remote UE. 
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Table A.5.2-21 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip:user3_public3@home3 .net SIP/2.0 
Via : 

To: sip : user3_public3®home3 . net ; tag = 66666 
From: sip :userl_publicl®homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123 .45.67.89 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 1304 RTP/AVP 96 97 
c=IN IP4 145.23.77.88 

b=AS : 25 . 4 
a=rtpmap : 94 AMR 

a=fmtp:94 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:95 telephone-event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
C=IN IP4 145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23-24. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 
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Table A.5.2-23 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_public3@home3 . net 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 20 

m=audio 3 04 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap : 94 AMR 

a=fmtp:94 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:95 telephone-event 
a=maxptime : 2 

m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 iyiP4V-ES 



25-26. SIP ACK request (from SCC-AS to remote UE) 
The SCC-AS sends a SIP ACK request to the remote UE. 

27-28. SIP re-INVITE request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP re-INVITE request to the controller UE, UE-1. 
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Table A.5.2-27 SIP INVITE request (SCC-AS to UE-1) 



INVITE sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=audio RTP/AVP 96 97 

m=video RTP/AVP 98 99 



29-30. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 

31-32. SIP ACK request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP ACK request to the controller UE, UE-1, in response to the SIP 200 (OK) response. 

33-34. SIP re-EWITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP re-INVITE request to the controUee UE, UE-2, to activate the video media 
components. 
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Table A.5.2-33 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip:userl j)ublic2@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

To : sip : userl_public2®homel . net ; 

From: sip : interUEtransf erOsccasl . homel . net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Ref erred-By : sip :userl_publicl®homel . net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=audio 3 04 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap : 94 AMR 

a=fmtp:94 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:95 telephone-event 
a=maxptime : 20 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendrecv 



35-36. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2, acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.5.2-35 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip :userl_public2@homel . net ; 


tag = 27365 


From: sip : interUEtransf er@sccasl 


homel.net; tag = 36527 


Call-ID: Cb03a0s09a2sdfglkj22222 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl_public2@homel 


net ;gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145 . 23.77. 88 


s = - 

c=145 .23.77.88 




t = 




m=audio RTP/AVP 97 




m=audio 13 04 RTP/AVP 96 97 




C=IN IP4 145.23.77.88 




b=AS:25.4 




a= r tpmap : 9 4 AMR 




a=fmtp:94 prof ile-level-id=0 




a=rtpmap:95 telephone -event 




a =maxpt ime : 2 




m=video 1302 RTP/AVP 98 99 




b=AS:75 




a=rtpmap:98 H2 63 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 
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37-38. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to the controUee UE, UE-2, in response to the SIP 200 (OK) response. 

39-40. SIP NOTIFY request (from SCC-AS to conroUer UE, UE-1) 

The SCC-AS sends a SIP NOTIFY request to the controller UE, UE-1, to inform about the success status of the 
inter-UE transfer. 

Table A.5.2-39 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip:userl j>ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To: sip :userl_publicl@homel .net ; tag=24680 

From: sip : interUEtransf er@sccasl . homel .net ; tag=13579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 
v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s=- 

c=145.23.77.88 
t = 

m=audio RTP/AVP 97 
m=audio 1304 RTP/AVP 96 97 
C=IN IP4 145.23.77.88 
b=AS:25.4 
a=rtpmap:94 AMR 
a=fmtp:94 prof ile-level-id=0 
a=rtpmap:95 telephone-event 
a=maxpt ime : 2 

m=video 13 02 RTP/AVP 98 99 
b=AS I 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



41-42. SIP 200 (OK) response (from - UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

A.5.3 Controller UE initiated media transfer from controllee UE to 
another controllee UE with subscription to dialog events 

The signalUng flow in figure A.5.3 describes the procedures for media transfer from one controllee UE to another 
controllee UE with persistent subscription to dialog events. 

NOTE 1 : For brevity not all SIP NOTIFY requests sent as a result of the subscription to the dialog event package 
are shown. 
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-29. Re-INVITE- 



-30. Re-INVITE- 
I 



-31. 200 OK- 



-32. 200 OK- 
—33. ACK— 



—35. NOTIFY — 
— 38. 200 OK — 
-39. Re-INVITE- 
— 42. 200 OK— 
43. ACK 



-^5. Re-INVITE- 
— 48. 200 OK — 
49. ACK 



-51. NOTIFY- 
-54. 200 OK- 



(Audio 2)- 



34. ACK- 



-(Audio 1, Video)- 



Figure A.5.3: Controller UE transfers a media from one controllee UE to another 

control lee UE 

1-2. SIP SUBSCRIBE request (from controller UE to SCC-AS) - see example in table A.5.3-1 

In order that the controller UE fetches the information about the session descriptions of the UEs within the 
collaborative session, the controller UE subscribes to the existing dialog between the controller UE and the SCC 
AS. 
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Table A.5.3-1 SIP SUBSCRIBE request (controller UE to SCC-AS) 



SUBSCRIBE sip:scc-as@homel.net SIP/2.0 






Via : 






To: sip : scc-as@homel . net ; tag= 24680 






From: sip:userl publicl@homel.net; tag=13579 






Event: dialog; call-id=" Cb03a0s09a2sdfglkj321576" , 


from-tag="54321' 


; to-tag= " 123456 " ; 


include -session- description 






Call -ID: Cb0 3a0s09a2sdfglkj4 90333 






CSeq: 1 SUBSCRIBE 






Max-Forwards: 70 






P -Preferred- Identity : 






Require: target-dialog 






Expires: 3600 






Target -dialog : cb0 3a0s09a2sdfglkj 321576 ; remote- tag= 


abode f ; local -tag= 


123456 


Contact : sip : user l_publicl®homel . net ; gr=urn :uuid: f £ 


ld4f ae-7dec-lldO- 


a765-00a0c91ewxyz 


CSeq: 






Allow: 






Accept : application/dialog-inf o+xml 






Content-Length: 







3-4, SIP 200 (OK) response (from SCC-AS to controller UE) 

The sec AS acknowledges the SIP SUBSCRIBE request by sending a SIP 200 (OK) response to the controller 
UE. 

5-6. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.5.3-5 

The sec AS sends a SIP NOTIFY request containing SDP for the remote UE so that the controller UE has the 
current state of the media for the collaborative session. 
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Table A.5.3-5 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip:userlj)ublicl@homel .net SIP/2.0 
Via : 

To: sip : userl_publicl®homel . net ; tag=13579 
From: sip : scc-asOhomel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : dialog 

Content-Type : application/dialog-info+xml 
Content-Length: (...) 



<?xml version= " 1 . " ? > 

<dialog-inf o xmlns="urn: ietf :params :xml :ns :dialog-info" 

version^ " " 
state= " full " 

entity^ " sip : scc-asohomel . net " > 
<dialog id="xxxx" call-id="f fafa" local-tag="dd" remote -tag="ee"> 

< state >confirmed</ state > 
<local> 

< identity display= " control lee UE" >sip : user2_publicl®homel . net</identity> 

< target >sip : user2_publicl@homel . net ; gr=urn : uuid: f 8 ld4fae-7dec -Ild0-a7 65-0 0a0c91e6bf6</ target > 

< session- description type= " application/sdp" > 
v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s = - 
t = 

m=audio 49174 RTP/AVP 96 97 
c=IN IP4 123 .45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
c=IN IP4 123.45.67.89 

b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1009 RTP/AVP 98 99 
c=IN IP4 123.112.67.87 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
</session-description> 

</local> 
<remote> 

<identity display^" remote UE" >tel : +l-237-555-2222</identity> 

<target >sip :user2_publicl@home2 . net ; gr=urn : uuid: 2ad8950e-4 8a5-4a74 -8d99-ad76cc7f c74</target> 

<session-description type="application/sdp" > 
v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

t = 

m=audio 49174 RTP/AVP 96 97 
c= IN IP4 132.54.76.98 
b=AS:25.4 
a=rtpmap : 96 AMR 

a=fmtp: 96mode-set=0 ,2,5,7; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=audio 44552 RTP/AVP 96 97 

b=AS:25.4 

a= r tpmap : 9 6 AMR 

a=fmtp: 96mode-set=0 , 2,5,7; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

c= IN IP4 132.54.76.98 
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m=video 1009 RTP/AVP 98 99 
c= IN IP4 132.54.76.98 
a=sendonly 
b=AS:75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

</session-description> 

</remote> 

</dialog> 
< /dialog- info 



7-8. SIP 200 (OK) response (from controller UE-1 to SCC-AS) 

The controller UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 

9-10. SIP REFER request (from controUer UE-1 to SCC-AS) - see example in table A.5.3-9 

There is an existing session with audio 1 and audio 2 between UE-2 (123.45.67.89) and the remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controllee UE, UE-3 
(123.1 12.67.87). The controller UE-1 attempts to transfer the audio 1 portion of this session to the controllee UE, 
UE-3. 

Table A.5.3-9 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-as@homel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag= 24680 

From: sip : userl_publicl@homel . net ; tag=13579 

Call -ID: Cb0 3a0s09a2sdfglkj4 90333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : sip : userl_publicl®homel . net 

Refer- To : <sip : userl_public3@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91eebf ebody=m%3Daudio%200%20RTP%2FAVP%200%0Dm%3Daudio%20 
49174%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%2 01009%2 0RTP%2FAVP%2 098%2 099> 

Require: target-dialog 

Target-dialog: cb03a0s09a2sdf glkj 321576 ; remote-tag=abcdef ; local-tag=123456 
Contact : <sip : userlpubliclohomel . net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz> ; +g . 3gpp . iut-controller 
Ref erred-By : sip : userl_publicl@homel .net 
Accept: message/sipf rag 
Content -Length: 



11-12. SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 

13-14. SIP NOTIFY request (from SCC AS to UE-1) - see example in table A.6.3-13 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 
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Table A.5.3-13 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To : sip : userl_publicl®homel . net ; tag=24 680 
From: sip : scc-asOhomel . net ; tag=13579 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires = 36 00 
Content-Type : message/sipf rag; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



15-16. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

17-18. SIP INVITE request (from SCC-AS to UE-3) - see example in table A.5.3-17 

Since the message 9-10 contains a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
audio Une which is not currently supported by another controUee UE than UE-2, the SCC AS reaUzes the 
procedure is for transferring the media from that controUee UE (UE-2) to controUee UE (UE-3). The SCC-AS 
sends a SIP INVITE request to the controUee UE, UE-3, to transfer the audio media component. The SDP in the 
SIP INVITE request lists the media lines within the collaborative session. In order to avoid UE-3 to start sending 
audio to the remote UE, the SCC-AS adds an a-line set to sendonly in the SDP offer. 

Table A.5.3-17 SIP INVITE request (SCC-AS to UE-3) 



INVITE sip :userl_public3@homel . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 SIP/2.0 
Via : 

To: sip : userl_public3®homel . net ; 
From: sip : scc-as@homel .net ; tag=12486 

Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendonly 
b=RR: 

b=RS : Om=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19-20. SIP 200 (OK) response (from UE-3 to SCC-AS) - see example in table A.5.3-19 

The controUee UE, UE-3, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 
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Table A.5.3-19 SIP 200 (OK) response (UE-3 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public3@homel.net; 


tag = xyzwv 


From: sip : scc-asohomel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userl public3@homel 


. net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.112.67.87 


s=- 

c=123 . 112 .67.87 




t = 




m=audio 3002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 




m=audio RTP/AVP 




m=video 1302 RTP/AVP 98 99 




a=recvonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





21-22. SIP ACK request (from SCC-AS to UE-3) 

The SCC-AS sends a SIP ACK request to UE-3 to acknowlege. 
23-24. SIP re-INVITE request (from SCC-AS to controUee UE, UE-2) - see example in table A.5.3-23 

The sec AS sends a SIP re-INVITE request to controUee UE, UE-2 to put Audio 1 on hold. 

Table A.5.3-23 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip:userl j>ublic2@home3 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip:userl j)ublic2@homel .net ; 
From: sip : scc-as@homel .net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 
Contact : 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

C=IN IP4 123.112.67.87 
t = 

m=audio 4 9174 RTP/AVP 96 97 

a=sendonly 

b=RR:0 

b=RS : 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=sendonly 
b=RR:0 



25-26. SIP 200 (OK) response (from UE-2 to SCC-AS) - see example in table A.5.3-25 

The controUee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 
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Table A.5.3-25 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public20homel.net; 


tag = xyzwv 


From: sip : scc-asohomel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userl public2®homel 


. net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s = - 

C=IN IP4 123.45.67.89 




t = 




m=audio 32324 RTP/AVP 96 97 




a=recvonly 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 





27-28, SEP ACK request (from SCC-AS to UE-2 ) 

The sec -AS sends a SIP ACK request to UE-2 to acknowlege. 
29-30 SIP re-INVITE request (from SCC-AS to remote UE) - see example in table A.5.3-29 
The SCC-AS sends a SIP re-INVITE request to the remote UE. 

Table A.5.3-29 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip:user2 j)ublicl@home3 .net ; SIP/2 . 
Via: 

To: sip:user2 j>ublicl@home2 .net ; tag=66666 
From: sip : scc-as@homel .net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact : sip : user l_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

t = 

m=audio 3002 RTP/AVP 96 97 
c= IN IP4 123.112.67.87 
a=rtpmap:0 PCMU/8000 
m=audio 34002 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
A=rtpmap:0 PCMU/8000 
m=video 1302 RTP/AVP 98 99 
c= IN IP4 123.112.67.87 
b=AS:75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



31-32. SIP 200 (OK) response (from remote UE to SCC-AS) - see example in table A.5.3-31 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 
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Table A.5.3-31 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user2_publicl®home2 . net ; 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c= IN IP4 132 .54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 iyiP4V-ES 
a=sendonly 



33-34. SIP ACK request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 

35-36. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.5.3-35 

The sec AS sends a SIP NOTIFY request containing SDP for the remote UE so that the controller UE can be 
aware about the change of state of the media for the collaborative session. 
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Table A.5.3-35 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip : user l_publicl@homel .net ; 
Via : 

To: sip : userl_publicl®homel . net ; tag=13579 
From: sip : scc-asOhomel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : dialog 

Content-Type : application/dialog-info+xml 
Content-Length: (...) 



<?xml version= " 1 . " ? > 

<dialog-info xmlns="urn: ietf :params :xml :ns :dialog-info" 

version^ " 1 " 
state= " full " 

entity^ " sip : scc-asohomel . net " > 
<dialog id="xxxx" call-id="f fafa" local-tag="dd" remote -tag="ee"> 

< state >confirmed</ state > 
<local> 

< identity display= " control lee UE" >sip : user2_publicl®homel . net</identity> 

< target >sip : user2_publicl@homel . net ; gr=urn : uuid: f 8 ld4fae-7dec -Ild0-a7 65-0 0a0c91e6bf6</ target > 

< session- description type= " application/sdp" > 
v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s = - 
t = 

m=audio 49174 RTP/AVP 96 97 
c=IN IP4 123 .45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp : 96mode-set=0 ,2,5,7; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
c=IN IP4 123.45.67.89 

b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp : 96mode- set=0 , 2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1009 RTP/AVP 98 99 
c=IN IP4 123.112.67.87 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
</session-description> 

</local> 
<remote> 

<identity display^" remote UE" >tel : +l-237-555-2222</identity> 

<target >sip :user2_publicl@home2 . net ; gr=urn : uuid: 2ad8950e-4 8a5-4a74 -8d99-ad76cc7f c74</target> 

<session-description type="application/sdp" > 
v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

t = 

c= IN IP4 132.54.76.98 

m=audio 4 9174 RTP/AVP 96 97 

b=AS:25.4 

a= r tpmap : 9 6 AMR 

a=fmtp: 96mode-set=0 ,2,5,7; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=audio 44552 RTP/AVP 96 97 

b=AS:25.4 

a= r tpmap : 9 6 AMR 

a=fmtp: 96mode-set=0 , 2,5,7; mode-change-period=2 
a=rtpmap:97 telephone -event 
a=maxpt ime : 2 

m=video 1009 RTP/AVP 98 99 
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a=sendonly 
b=AS:75 

a=rtpmap:98 H2 63 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

</session-description> 

</remote> 

</dialog> 
< /dialog- info 



37-38. SIP 200 (OK) response (from controller UE-1 to SCC-AS) 

The controller UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 

39-40. SIP re-EWITE request (from SCC-AS to controUee UE, UE-2) - see example in table A.5.3-39 

The SCC-AS sends a SIP re-INVITE request to UE-2 to remove the audio 1 media component. 

Table A.5.3-39 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip :userl_public2@home3 . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip :userl_public2®homel .net ; 
From: sip : scc-as@homel .net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

C=IN IP4 123.112.67.87 
t = 

m=audio RTP/AVP 
m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 



41-42. SIP 200 (OK) response (from UE-2 to SCC-AS) - see example in table A.5.3-41 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 
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Table A.5.3-41 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public20homel.net; 


tag = xyzwv 


From: sip : scc-asohomel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userl public2®homel 


. net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s = - 

C=IN IP4 123.45.67.89 




t = 




m=audio RTP/AVP 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 





43-44. SEP ACK request (from SCC-AS to UE-2) 

The sec -AS sends a SIP ACK request to UE-2 to acknowlege. 
45-46. SIP reJNVITE request (from SCC-AS to controUee UE; UE-3) - see example in table A.5.3-45 
The SCC-AS sends a SIP reJNVITE request to UE-3 to activate the audio 1 media component. 

Table A.5.3-45 SIP re-INVITE request (SCC-AS to UE-3) 



INVITE sip:userl j)ublic3@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip:userl j>ublic3@homel .net ; 
From: sip : scc-as@homel .net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Referred-By: sip:userl_publicl@homel .net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

C=IN IP4 123.112.67.87 
t = 

m=audio 4 9174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendrecv 
m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
b=AS:75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendonly 



NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

47-48. SIP 200 (OK) response (from controllee UE; UE-3 to SCC AS) 

Controllee UE, UE-3 sends a SIP 200 (OK) response to the SCC AS. 
49-50. SIP ACK request (from SCC-AS to UE-3) 
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The sec- AS sends a SIP ACK request to the controUee UE, UE-3. 

51-52. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.5.3-51 

The sec AS sends a SIP NOTIFY request containing SDP of the SIP 200 (OK) response received from the 
controUee UE, UE-3. 

Table A.5.3-51 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip : user l_publicl@homel .net ; 
Via: 

To: sip:userl_publicl®homel .net ; tag=13579 
From: sip : scc-as®homel .net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Content-Type: message/sipf rag ; version=2 . ; 
Content -Length: (...) 

SIP/2.0 200 OK 

To: sip:userl j)ublic3@homel .net ; tag = xyzwv 
From: sip : scc-as@homel .net ; tag = 12486 
Call-ID: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

c=123.112.67.87 
t = 

m=audio 3002 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=audio RTP/AVP 
m=video 1302 RTP/AVP 98 99 
a=recvonly 
b=AS:75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



53-54. SIP 200 (OK) response (from controUer UE to SCC-AS) 

The controUer UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 

A.5.4 Controller UE initiated media transfer from controUee UE to 
anotlier controUee UE 

The signaUing flow in figure A.5.4 describes the procedures for media transfer from one controUee UE to another 
controUee UE. 
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-28. SIP re- INVITE— 
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Figure A.5.3A: Controller UE transfers a media from one controllee UE to another controllee UE. 



1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio 1 and audio 2 between UE-2 (123.45.67.89) and the remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controllee UE, UE-3 
(123.112.67.87). The Controller UE attempts to transfer the audio 1 portion of this session to the controllee UE, 
UE-3. 
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Table A.5.3A-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip: scc-as@homel .net SIP/2.0 
Via : 

To: sip : scc-asohomel . net ; tag= 24680 

From: sip : userl_publicl®homel . net ; tag=13579 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : sip : userl_publicl@homel . net 

Refer- To : <sip : userl_public3®homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO-aVeB- 
OOaOcSleSbf 6body=m%3Daudio%200%20RTP%2FAVP%200%0Dm%3Daudio%20 
49174%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%201009%20RTP%2FAVP%2098%2099> 

Require: target-dialog 

Target-dialog : cb03a0s09a2sdfglkj 321576 ; remote-tag=abcdef ; local-tag=123456 

Ref erred-By : sip : userl_publicl®homel . net 

Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz> ; +g . 3gpp . iut-controller 
Accept: message/sipf rag 
Content-Length: 



3-4, SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.5.3A-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 

To: sip:userl j>ublicl@homel .net ; tag=24 680 
From: sip : scc-as@homel .net ; tag=13579 
Call-ID: Cb03a0s09a2sdfglkj 12345 
CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip : scc-as@homel .net 
Allow: 

Event : refer 

Subscript ion- State : active; expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from controller UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP INVITE request (from SCC-AS to UE-3) 

Since the message 1-2 contains a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
audio line which is not currently supported by another controllee UE than UE-2, the SCC AS realizes the 
procedure is for transferring the media from that controllee UE (UE-2) to controllee UE (UE-3). The SCC-AS 
sends a SIP INVITE request to the controUee UE, UE-3, to transfer the audio media component. The SDP in the 
SIP INVITE request lists the media lines within the collaborative session. In order to avoid UE-3 to start sending 
audio to the remote UE, the SCC-AS adds an a-line set to sendonly in the SDP offer. 
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Table A.5.3A-3 SIP INVITE request (SCC-AS to UE-3) 



INVITE sip:userl j)ublic3@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

To : sip : userl_public3®homel . net ; 
From: sip : scc-asOhomel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendonly 
b=RR: 

b=RS : Om=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 

a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-3 to SCC-AS) 

The controUee UE, UE-3, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.5.3A-4 SIP 200 (OK) request (UE-3 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip :userl_public3®homel . net ; 


tag = xyzwv 


From: sip : scc-as®homel .net ; tag 


= 12486 


Call-ID: 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl public3®homel 


. net ;gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c91e6bf 6 


Allow : 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.112.67.87 


s = - 

c=123 . 112 .67.87 




t = 




m=audio 3002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 




m=audio RTP/AVP 




m=video 1302 RTP/AVP 98 99 




a=recvonly 




b=AS:75 




a=rtpmap:98 H2 63 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





13-14. SIP ACK request(from SCC-AS to UE-3) 

The SCC-AS sends a SIP ACK request to UE-3 to acknowledge. 
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15-16. SIP re-EWITE request (from SCC-AS to controUee UE, UE-2) 

The sec AS sends a SIP re-INVITE request to controUee UE, UE-2 to put Audio 1 on hold. 

Table A.5.3A-5 SIP INVITE request (SCC-AS to controUee UE, UE-2) 



INVITE sip : user l_public2@home3 . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip :userl_public2@homel .net ; 
From: sip : scc-as@homel .net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=sendonly 
b=RR: 
b=RS : 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=sendonly 
b=RR: 



17-18. SEP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2 acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.5.3A-6 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip : userl_public2@homel . net ; 


tag = xyzwv 


From: sip : scc-as@homel .net ; tag 


= 12486 


Call-ID: 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl_public2@homel 


.net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s=- 

C=IN IP4 123.45.67.89 




t = 




m=audio 32324 RTP/AVP 96 97 




a=recvonly 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 





19-20. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to UE-2 to acknowledge. 
21-22. SIP re-EWITE request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP re-INVITE request to the remote UE, UE-4. 
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Table A.5.3A-7 SIP INVITE request (SCC-AS to remote UE, UE-4) 



INVITE sip:user2 j)ublicl@home3 .net ; SIP/2 . 
Via : 

To : sip : user2_publicl®home2 . net ; tag=6 6666 
From: sip : scc-asOhomel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

t = 

m=audio 3002 RTP/AVP 96 97 
c= IN IP4 123.112.67.87 
a=rtpmap:0 PCMU/8000 
m=audio 34 02 RTP/AVP 96 97 
C=IN IP4 123 .45.67.89 
A=rtpmap:0 PCMU/8000 
m=video 13 02 RTP/AVP 98 99 
c= IN IP4 123.112.67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



23-24. SIP 200 (OK) response (from remote UE, UE-4 to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 

Table A.5.3A-8 SIP 200 (OK) request (UE-4 to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To: 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity: 

Contact : sip :user2_publicl@home2 .net ; 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

c= IN IP4 132.54.76.98 

t = 

m=audio 49174 RTP/AVP 96 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 , 2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=video 10 09 RTP/AVP 98 99 

a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
a=sendonly 
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25-26. SIP ACK request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 
27-28. SIP re-EWITE request (from SCC-AS to controUee UE, UE-2) 

The SCC-AS sends a SIP re-INVITE request to UE-2 to remove the audio 1 media component. 

Table A.5.3A-9 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip: user lpublic2@home3 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip:userl_public2®homel .net ; 
From: sip : scc-as@homel .net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 
m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 



29-30, SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controUee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.5.3A-10 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via: 




To: sip:userl j)ubIic2@homel .net ; 


tag = xyzwv 


From: sip : scc-as@homel .net ; tag 


= 12486 


Call-ID: 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userlj)ublic2@homel 


.net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s=- 

C=IN IP4 123.45.67.89 




t = 




m=audio RTP/AVP 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 





31-32. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to UE-2 to acknowledge. 
33-34. SIP re-INVITE request (from SCC-AS to controUee UE, UE-3) 

The SCC-AS sends a SIP re-INVITE request to UE-3 to activate the audio 1 media component. 

NOTE: The SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 
was generated by the SCC AS due to third party call cotrol to allow sending this SIP re-INVITE request. 
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Table A.5.3A-11 SIP re-INVITE request (SCC-AS to UE-3) 



INVITE sip:userl j)ublic3@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

To : sip : userl_public3®homel . net ; 
From: sip : scc-asOhomel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Ref erred-By : sip :userl_publicl®homel . net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

C=IN IP4 123.112.67.87 

t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendrecv 
m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 iyiP4V-ES 

a=sendonly 



35-36. SIP 200 (OK) response (from controUee UE, UE-3 to SCC-AS) 

Controllee UE, UE-3 sends a SIP 200 (OK) response to the SCC AS. 
37-38. SIP ACK request (from SCC-AS to UE-3) 

The SCC-AS sends a SIP ACK request to the controllee UE, UE-3. 

39-40. SIP NOTIFY request (from SCC-AS to controUer UE, UE-1) 

The SCC AS sends a SIP NOTIFY request containing SDP of the SIP 200 (OK) response received from the 
controllee UE, UE-3. 
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Table A.5.3A-12 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : user l_publicl@homel .net ; 
Via : 

To: sip : userl_publicl®homel . net ; tag=13579 
From: sip : scc-asOhomel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as®homel . net 
Allow: 

Event : refer 

Content-Type: message/sipf rag ; version=2 . ; 
Content-Length: (...) 

SIP/2.0 200 OK 

To: sip : userl_public3®homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
S = - 

c=123 . 112 .67.87 
t = 

m=audio 3 02 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=audio RTP/AVP 
m=video 13 02 RTP/AVP 98 99 
a=recvonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



41-42. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC-AS. 



A.6 Signalling flows for release of collaborative session 
for inter-UE transfer 

A.6.1 Introduction 

The signalling flows for release of Collaborative Session demonstrate how the session is released by the Controller UE 
or by the remote party UE. The following signalling flows are included: 

- subclause A.6. 2 shows an example where the Controller UE initiates the release of a Collaborative Session. It 

demonstrates how the service control signalling and media path between the Controller UE and remote UE and 
the media path between the Controllee UE and the remote UE are released as a result of the session release; and 

- subclause A.6. 3 shows an example where the remote UE initiates the release of a Collaborative Session. 



A.6. 2 Controller UE releases collaborative session 

In this example, session release is initiated by the Controller UE (UE 1), which is involved in the Collaborative Session 
with UE 2 and the remote UE (UE 3). The SCC AS ensures that all Controllee UEs involved in the Collaborative 
Session receive a request for session release in order to completely release the session ongoing with the remote UE. 
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-2. SIP BYE- 



— 11. SIP BYE 

-12. SIP 200 (OK)- 



-15. SIP 200 (OK)- 
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-3. SIP BYE- 
-4. SIP BYE- 



-5. SIP BYE- 



-8. SIP 200 (OK)- 
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—10. SIP BYE — 
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6. SIP BYE — 

-7. SIP 200 (OK^ 



Figure A.6.2-1 : Release of Collaborative Session initiated by Controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalling with the SCC AS. 

2-3. SIP BYE request (UE 1 to SCC AS via intermediate EM CN subsystem entities) 

UE 1, acting as the Controller UE, initiates session release by sending a SIP BYE request towards the SCC AS. 
There is no Inter UE transfer specific content in the SIP BYE request. 

4-6. SIP BYE request (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 3 indicating to the remote UE that the Controller UE requests 
that the session is to be released. 

7-9. SIP 200 (OK) response (UE 3 to SCC AS via intermediate EM CN subsystem entities) 

UE 3 responds to the received SIP BYE request with a SIP 200 (OK) response. 

10-11. SIP BYE request (SCC AS to UE 2 via intermediate EM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA, sends a SIP BYE request towards UE 2 to release the dialog it is 
involved in with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the SIP 
BYE request. 
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NOTE 1: The SIP BYE request to UE 2 (step 10) can occur in parallel with the SIP BYE request to UE 3 (step 4). 

Alternatively, the SCC AS can send the SIP BYE request to UE 2 prior to sending the SIP BYE request to 
UE3. 

12-13. SIP 200 (OK) response (UE 2 to SCC AS via intermediate EM CN subsystem entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

14-15 SIP 200 (OK) response (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 2 and UE 3, the SCC AS responds to the SIP BYE request 
from UE 1 wdth a SIP 200 (OK) response. 

NOTE 2: The SIP 200 (OK) response in step 7 can be sent earlier by the SCC AS in response to the SIP BYE 

request received from UE l(step 3). For example, the SCC AS can send the SIP 200 (OK) response to UE 
1 after receiving the SIP 200 (OK) response from UE 3 (step 9). 

A.6.3 Remote UE releases collaborative session 

In this example, session release is initiated by the remote UE (UE 3). UE 1 and UE 2 are included in a Collaborative 
Session with the remote UE. The SCC AS ensiu'es that all Controllee UEs involved in the Collaborative Session receive 
a request for session release in order to completely release the ongoing session. 
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intermediate iiVI 
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entitities 



SCC AS 
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1 . Collaborative Session involving UE 1 and UE 2 in a dialog with UE 3. UE 1 is the Controller UE and UE 2 is the Controlee UE. UE 3 is the remote 

end UE. 



Service control signalling- 

l\/ledia path between UE1 and UE 3- 



-6. SIP BYE- 



-8. SIP BYE- 



-9. SIP 200 (OK)- 



-11. SIP 200 (OK)- 



■l\/ledia path between UE2 and UE 3- 



-3. SIP BYE- 



-4. SIP BYE- 



-5. SIP BYE- 



-7. SIP BYE- 



-10. SIP 200 (OK)- 



-12. SIP 200 (OK)- 



-13. SIP 200 (OK) — 
14. SIP 200 (OK)- 



-2. SIP BYE- 



-15. SIP 200 (OK)- 

Figure A.6.3-1 : Release of Collaborative Session initiated by remote UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 
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1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalUng with the SCC AS. 

2-4. SIP BYE request (UE 3 to SCC AS via intermediate IM CN subsystem entities) 

The remote UE, UE 3, initiates session release by sending a SIP BYE request towards the Controller UE via the 
SCC AS serving the Controller UE. There is no Inter UE transfer specific content in the SIP BYE request. 

5-6. SIP BYE request (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 1, indicating to UE 1 that the remote UE requests that the 
session is to be released. 

7-8. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA sends a SIP BYE request to UE 2 to release the dialog it is involved in 
with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the SIP BYE request. 

NOTE 1: Step 7 can occur in parallel with step 5. Alternatively, step 7 can occur prior to step 5. The order in which 
the SCC AS sends the SIP BYE requests is not considered to be important. 

9-10. SIP 200 (OK) response (UE 1 to SCC AS via intermediate IM CN subsystems entities) 

UE 1 responds to the received SIP BYE request with a SIP 200 (OK) response. 
NOTE 2: Step 9 can occur immediately after UEl has received the SIP BYE request in step 6. 
11-12. SIP 200 (OK) response (UE 2 to SCC AS via intermediate IM CN subsystems entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

13-15. SIP 200 (OK) response (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 1 and UE 2, the SCC AS responds to the SIP BYE request 
fi-om UE 3 with a SIP 200 (OK) response. 

NOTE 3: Step 13 can occur after the SCC AS has received the SIP BYE request step 4 since it is not necessary to 
wait for SIP BYE requests to UEl and UE2. 



A.7 Signalling flows for addition and deletion of media 
within collaborative session for inter-UE transfer 

A.7.1 Introduction 

This subclause shows signalling flows for adding and releasing of mediacomponent by the controller UE. Four different 
scenarios are considered in this subclause: 

scenario where the controller UE adds a new media component on a controllee UE. The procedures in this 
subclause are the same as the procedures described in subclause A.4.3 with the exception that upon the receipt of 
a SIP REFER request from the controller UE, the SCC AS generates a SIP re-INVITE request within the dialog 
to the controllee UE instead of a SIP INVITE request; 

- scenario where the controller UE releases a media component from the controller UE, see subclause A.7. 2.1; 

- scenario where the controller UE releases a media component from the controllee UE, see subclause A. 14.2.2.1; 
and 

scenario where the controller UE releases a media component from the controllee UE and that causes the 
termination of the collaborative session, see subclause A.7. 2.2.2. 
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A.7.2 Controller UE releases media 



A.7.2.1 Controller UE releases media flow on controller UE 




1. re-INVITE 
Media-A=0 ' 



10. 200 (OK) 
-c= Remote UE- 
Media-A=0 



11.ACK- 



2. re-INVITE_ 
Media-A=0 

3. re-INVITE 
c=UE-1 

- Medla-A=0 - 
c=UE-2 
Medla-B 



6. 200 OK 
c=UE-1 
-Medla-A=0- 
c=UE-2 
Medla-B 

— 7.ACK— 



4. re-INVITE 

c=UE-1 
- Medla-A=0 - 
c=UE-2 
Medla-B 
I 

5. 200 OK 
c=UE-1 
-Medla-A=0— 
c=UE-2 
Medla-B 



-8.ACK- 



9. 200 (OK) 
-c=Remote UE- 
Medla-A=0 



-12.ACK- 



■Collabaratlve session control 1 

^ Medla-B between UE-2 and Remote UE- 



Figure A.7.2.1 : Controller UE releases media flow on controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-1 (controller 
UE) removes the media A flow that is active on the remote UE. 

1. SIP re-EVVITE request (UE-1 to intermediate EM CN subsystem entities)- see example in table A.7.2.1-1 

UE-1 sends a SIP re-INVITE request towards the remote UE indicating Media A is to be removed in the SDP 
offer. 
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Table A.7.2.1-1: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :userR_public@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6> SIP/2 . 
Via : SIP/2 . 0/UDP [3333 : : eee : f f f : aaa :bbb] : 13 5 7 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 
c=8642; port-s=7531 

Contact : <sip : userlpublicohomel . net > ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c67t 6br4> ; +g . 3gpp . iut -controller 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 

Accept: application/sdp , application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 :: aaa :bbb : ccc : ddd 

s=- 

t = 

m=audio RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 PCMU/8000 

m=video RTP/AVP 98 

C=IN IP6 4444 : :aaa:bbb:CCC:ddd 

a=rtpmap:98 MPV/90000 



2. SIP re-EWITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS according to 
standard IMS procedure. 

3. SIP re-EWITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-3 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, sets the port 
number for media A to 0, and forwards it towards the remote UE through the intermediate IM CN subsystem 
entities. 
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Table A.7.2.1-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userRpublic2@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> IP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bK240f34 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s = - 
t = 

m=audio RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 MPV/90000 

m=video 8888 RTP/AVP 98 

c=IN IP6 4444 :: aaa:bbb: ccc :ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-EmXE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the remote UE according to 
standard IMS procedure. 

5. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-5 

The remote UE sends a SIP 200 (OK) response with an SDP answer. 

Table A.7.2.1-5: SIP 200 (OK) response (remote UE to IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=dahtadf z4radgs . 12 , SIP/2. 0/UDP 
scscf 2 .homel .net ;branch=hsdf Idf 343 . 12 , SIP/2 . 0/UDP 
scscfl .homel .net ;branch=hsdfldf 563 22cc . 13 , SIP/2 . 0/UDP 
sccasl . homel . net ;branch=z9hG4bKnas34r2 .21 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp ; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: CCC: ddd 

t = 

m=audio RTP/AVP 97 
a=rtpmap:97 MPV/90000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
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6. SIP 200 (OK) response 

7. SIP ACK request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS sends a SIP ACK request to the remote UE through the intermediate IM CN subsystem entities. 

8. SIP ACK request (intermediate EM CN subsystem entities to remote UE) 

9-10. SIP 200 (OK) response (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response with an SDP answer indicating that Media-A has been removed 
11-12. SIP ACK request (controller UE to SCC AS) 



ETSI 



3GPP TS 24.337 version 1 0.8.0 Release 10 1 26 ETSI TS 1 24 337 V1 0.8.0 (201 3-07) 

A.7.2.2 Controller UE releases media flow on controllee UE 
A.7.2.2.1 Controller UE removes media at the controllee UE 
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UE-1 



UE-2 



Intermediate 
IM CN entities 



sec AS 



Remote UE 



REFER 
;[er-To: UE-2 - 
<remove Media-B> 



Re 



4. 2 02 Accepted- 



li.NOTIFY- 
200 OK- 



•Collaborative session contrDi 1 

Media-A between U[;-1 and Remote UE- 



-Media-B bfitween UE-2 and Remcte UE- 
-Media-C between UE-2 and Remote UE- 



-14. re-INVITE- 
-15. 200 OK— 



-18.ACK- 



-26. re-INVITE- 
—27. 200 OK— 



3|0.NOTIFY- 
1.200OK- 



•Collabaratlve session contrpi- 

Media-A between Uf-1 and Remote UE- 



2. REFER 
- Refer-To: UE-2 ► 
<remove Media-B> 

<-3. 202 Accepted — 
4 5.N0TIFY 



-8. 200 OK- 



9. UPDATE 
c1=UE-1 
Media-A 
_ c2=UE-2 
Media-B 

a=sendonly 
b=RR:0 
b=RS:0 



10. UPDATE- 

11. 200 OK 
c=Remote UE 

Media-A 
_c=Remote UE_ 
Media-B 
a=recvonly 
b=RR:0 
b=RS:0 



-12. 200 OK- 



-13. re-INVITE- 



-16.200 OK- 



-1 7. ACK- 



19. re-INVITE 
c=UE-1 

- Media-A 

c=UE-2 
Media-B=0 

20. re- 
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INVITE 
E-1 
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E-2 
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21. 20 
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22. 200 (OK) 
_c=Remote UE_ 
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23. ACK 
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-28. 200 OK- 
-29.NOTIFY- 



-32. 200 OK- 
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B=0 



24. ACK- 
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NOTE 1 : For clarity, the SIP 100 (Trying) responses are not sliown in ttie signalling flow. 

Figure A.7.2.2.1 iControiier UE remove media at thie controllee UE 

1-2. SIP REFER request (controller UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-1 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia 
session on his device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media 
flows and a voice (Media C) media flow. The controller UE wants to remove the video media (Media B) 
component on the controllee UE. 

Table A.7.2.2.1 -1 SIP REFER request (UE-1 to SCC AS) 



REFER sip: interUEtransferSsccasl .homel .net SIP/2.0 
Via: 

To: sip: interUEtransf erSsccasl .homel .net 
From: sip :userl j)ublicl@homel .net ; tag =13579 
Call- ID: Cb03a0s09a2sdfglkj490333 
CSeq: 93809824 REFER 
Max- Forwards : 70 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel .net> 

Refer-To: <sip:user2 j>ublic2@home2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6? 

body=m%3Daudio%2 00%2 0RTP%2FAVP%2 097%0Dm%3Daudio%2 04568%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 00%2 0R 

TP%2FAVP%2098> 
Require: target-dialog 

Target-dialog : cb03a0s09a2sdf glkj 13579 ; to-tag=abcdef ; f rom-tag=123456 
Referred- By : sip : userlpubliclOhomel .net 

Contact : <sip :userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz> ; +g . 3gpp . iut-controller 
Allow: 

Accept: message/sipf rag 
Content-Length: 

3-4. SIP 202 (Accepted) response 

The SCC-AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example 
in table A.7.2.1-5 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.7.2.2.1-5 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip:userl j>ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To: sip:userl j)ublicl@homel .net ; tag=13579 

From: sip : interUEtransf er@sccasl . homel .net ; tag=2255 

Call-ID: 

CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- state : active;expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC AS. 

9-10. SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem entities) - see 
example in table A.7.2.2.2-9. 
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The sec AS prepares the removal of the media component received by the controUee UE-2 and sent by the 
remote UE. 



Table A.7.2.2.2-9: SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem 

entities) 



UPDATE sip :userR_publicl®homel . net ; gr=urn :uuid 


f 81d4f ae-7dec- 


Ild0-a762 


-00a0c91e6bf 6 SIP/2.0 


Via : 








To : 








From : 








Call-ID: 








Cseq : 








Contact: <sip: userl publicohomel . net> ; gr=urn 


uuid: f 81d4fae- 


7dec-lld0 


-a765-00a0c67t6br4> 


Allow : 








Content-Type: application/sdp 








Content -Length: (...) 








v=0 








o=- 2987933615 2987933615 IN IP6 3333 : :aaa:bbb 


ccc : ddd 






s=- 
t = 








m=audio 6666 RTP/AVP 97 








c=IN IP6 3333 : :aaa:bbb:ccc:ddd 








a=rtpmap:97 PCMU/8000 








m=video 6668 RTP/AVP 98 








a=sendonly 








b=RR : 








b=RS : 








c=145 .23.77.88 








b=AS : 75 








a=rtpmap:98 H2 63 








a=fmtp:98 prof ile-level-id=0 









11-12. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-11. 

Remote UE send a SIP 200 (OK) response with SDP answer. 
Table A.7.2.2.2-11 SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

Cseq: 

Contact : <sip :userR_publicl@homel .net ; gr=urn:uuid: f 81d4f ae- 7dec- Ild0-a762 -00a0c91e6bf 6> 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb :: ccc : ddd 

s=- 

t=0 

m=audio 4444 RTP/AVP 97 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 

a=rtpmap:9777 PCMU/8000 

m=video 6666 RTP/AVP 98 

a=recvonly 

b=RR:0 

b=RS : 

c=145.23.77.88 
b=AS:75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 



13. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.1-13 
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The sec AS sends a SIP re-INVITE request towards the ControUee UE (UE-2). 

Table A.7.2.2.1-13 SIP re-INVITE request (SCC-AS to IM CN subsystem entities) 



INVITE sip:user2 j>ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 

Via: 

Route : 

To: sip:user2 j)ublicl@homel .net ;abcdef 
From: sip:user3 j>ublic3@home3 .net ; tag=123456 
Call-ID: 
CSeq: 

Max- Forwards : 
Require : 

Referred-By: sip:userl_publicl@homel .net 

Contact : sip:user3 j>ublic3@home3 .net ;gr=urn:uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

t = 

m=audio RTP/AVP 97 
m=audio 4568 RTP/AVP 97 
c=123.112.67.87 
b=AS:75 

a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=sendonly 



14. SIP re-EWITE request (intermediate EM CN subsystem entities to UE-2) 

15-16, SEP 200 (OK) response (UE-2 to SCC AS througli intermediate EM CN subsystem entities) 

17-18. SIP ACK request (from SCC-AS to UE-2) 

19. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2-19 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, set the port 
number for media B to 0, and forwards it to the remote UE through the intermediate IM CN subsystem entities. 
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Table A.7.2.2.1-19: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted-Identity: "John Doe" <sip:userl_publicl@homel .net> 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userlpublicOhomel . net> ; gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content -Length: ( . . ) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 3333 : :aaa:bbb:ccc:ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=audio 4567 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP re-EVVITE request (intermediate EM CN subsystem entities to remote HE) 

21. SIP 200 (OK) response (remote UE to intermediate EM CN subsystem entities) - see example in 
table A.14.2.1-21 

The remote UE sends a SIP 200 (OK) response with an SDP answer. 
Table A.7.2.2.1-21 SIP 200 (OK) (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=fsc35avhthaz4 . 22 , SIP/2 . 0/UDP 

scscfl .homel .net ;branch=fsc35avhthaz4 . 12 , SIP/2 . 0/UDP 

sccasl .homel .net;branch=z9hG4bKnas34r2 . 14 
From: 
To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb :: ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:9777 PCMU/8000 
m=audio 4545 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



22. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 
23-24. SIP ACK request (SCC AS to remote UE) 

25-26. SIP re-INVITE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 
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sec AS sends a SIP re-INVITE request towards ControUee UE (UE-2). 

NOTE: The SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 
was generated by the SCC AS due to third party call cotrol to allow sending this SIP re-INVITE request. 

Table A.7.2.2.1-25 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip:user2 j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 
Route : 

To : sip : user2 jubliclohomel . net ; abcdef 

From : sip :user3_public3@home3 .net ; tag=123456 

Call-ID: 
CSeq: 

Max- Forwards : 

Contact : sip :user3_public3@home3 .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow : 

Referred- By : sip : userl_publicl@homel .net 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 97 
m=audio 4568 RTP/AVP 97 
c=123.112.67.87 
b=AS : 75 

a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



27-28. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

29-30. SIP NOTIFY request (SCC-AS to UE-l)-see example table A.7.2.2.1-21 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status of the 
inter-UE transfer. 

Table A.7.2-2.1-29 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip:userl j>ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: 

To: sip:userl j)ublicl@homel .net ; tag = 13579 

From: sip : interUEtransf er@sccasl . homel .net ; tag=2255 

Call-ID: 

CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s=- 

m=audio 3434 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=sendonly 



31-32. SIP 200 OK response (UE-1 to SCC AS) 
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The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 OK response to the SCC 
AS. 
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A.7.2.2.2 Controller UE remove the controllee UE from the collaborative session 
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Figure A.7.2.2.2:Controller UE remove the controllee UE from the collaborative session 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1-2. SIP REFER request (controller UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-1 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia 
session on his device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media 
flow. The controller UE wants to remove the controllee UE from the collaborative session. 

Table A.7.2.2.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip: interUEtransfer@sccasl .homel .net SIP/2.0 
Via: 

To: sip: interUEtransf erSsccasl .homel .net 

From: sip :userl_publicl@homel .net ; tag = 13579 

Call-ID: Cb03a0s09a2sdfglkj490333 

CSeq: 93809824 REFER 

Max- Forwards : 70 

P- Preferred- Identity : 

Refer-To : <sip :user2_public2@home2 .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a762 - 

00a0c91e6bf 6 ;method=BYE> 
Require: target -dialog 

Target -dialog: Cb03a0s09a2sdfglkj 13579 ; to-tag=abcdef ; f rom-tag=123456 
Contact : <sip :Userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz>; +g. 3gpp . iut- controller 
Allow: 

Referred-By: sip:userl_publicl@homel .net 
Accept : 
Content -Type : 
Content -Length: 



3-4. SIP 202 (Accepted) response 

The sec AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities) - see example 
in table A.7.2.2.2-5 

The SCC AS sends a SIP NOTIFY request to UE-1 to notify imphcit subscription to the SIP REFER request 
results. 

Table A.7.2.2.2-5 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY 
Via: 

To: sip:userl j)ublicl@homel .net ; tag=13579 

From: sip : interUEtransf er@sccasl . homel .net ; tag=2255 

Call-ID: 

CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- State : active;expires=3600 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (UE-1 to SCC AS through mtermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) to the SCC AS. 
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9-10. SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem entities) - see 
example in table A.7.2.2.2-9. 

The SCC AS prepares the removal of the controllee UE-2 from the collaborative session by stopping the media 
received by the controllee UE-2 and sent by the remote UE. 



Table A.7.2.2.2-9: SIP UPDATE request (SCC AS to Remote UE through intermediate IM CN 

subsystem entities) 



UPDATE sip :userR_publicl@homel .net ; gr=urn:uuid 


f 81d4f ae-7dec- 


lldO 


-a762 


-00a0c91e6bf 6 SIP/2.0 


Via: 










To: 










From: 










Call-ID: 










Cseq: 










Contact: <sip: userl_public@homel .net>; gr=urn 


uuid: f 81d4f ae- 


7dec 


-lldO 


-a765-00a0c67t6br4> 


Allow: 










Content - Type : application/sdp 










Content -Length: (...) 










v=0 










o=- 2987933615 2987933615 IN IP6 3333 : :aaa:bbb 


ccc : ddd 








s=- 
t=0 










m=audio 6666 RTP/AVP 97 










c=IN IP6 3333 : :aaa:bbb:ccc:ddd 










a=rtpmap:97 PCiyrU/8000 










m=video 6668 RTP/AVP 98 










a=sendonly 










b=RR:0 










b=RS : 










c=145.23.77.88 










b=AS : 75 










a=rtpmap:98 H263 










a=fmtp:98 prof ile-level-id=0 











11-12. SIP 200 (OK) response (Remote UE to intermediate EM CN subsystem entities) - see example in 
table A.14.2.2.2-11. 

Remote UE sends a SIP 200 (OK) response with SDP answer. 
Table A.7.2.2.2-11 SIP 200 (OK) response (Remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 




Via: 




To: 




From : 




Call-ID: 




Cseq : 




Contact: <sip:userR publiciohomel . net ; gr=urn :uuid : f ( 


31d4fae-7dec-lld0-a762-00a0c91e6bf 6> 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 2987933300 2987933300 IN IP6 5555 : : aaa :bbb : : ccc 


ddd 


s=- 
t=0 




m=audio 4444 RTP/AVP 97 




C=IN IP6 5555 : :aaa:bbb: :ccc:ddd 




a=rtpmap : 9777 PCMU/8000 




m=video 6666 RTP/AVP 98 




a=recvonly 




b=RR: 




b=RS : 




c=145 .23.77.88 




b=AS : 75 




a=rtpmap:98 H2 63 




a=fmtp:98 prof ile-level-id=0 
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13-14. SIP BYE request (SCC AS to UE-2 through intermediate EM CN subsystem entities) 

The SCC AS sends a SIP BYE request towards the controllee UE (UE-2). 

15-16. SIP 200 (OK) response (UE-2 to SCC AS through intermediate EM CN subsystem entities) 

17. SIP re-EVVITE request (SCC AS to intermediate EM CN subsystem entities) - see example in 
table A.14.2.2.2-17 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, set the port 
number for media B to 0, and forwards it to the remote UE through the intermediate IM CN subsystem entities. 

Table A.7.2.2.2-17: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl®homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 12 7 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Length: 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 3333 : :aaa:bbb:ccc:ddd 
t=0 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

19. SIP 200 (OK) response (remote UE to intermediate EM CN subsystem entities) - see example in 
table A.14.2.2.2-19 

The remote UE sends a SIP 200 (OK) response with SDP answer. 
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Table A.7.2.2.2-19 SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=f sc35avhthaz4 .22 , SIP/2 . 0/UDP 

scscf 1 .homel . net ; branch=f sc35avhthaz4 . 12, SIP/2 . 0/UDP 

sccasl .homel .net;branch=z9hG4bKnas34r2 . 14 
From : 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type : application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 : : aaa :bbb : : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap : 9777 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 
21-22. SIP ACK request (SCC AS to remote party) 

23-24. SIP NOTIFY request (SCC-AS to UE-l)-see example in table A.7.2.2.2-25 

The SCC-AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status of the 
inter-UE transfer. 

Table A.7.2.2.2-23 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via: 

To: sip :userl_publicl@homel .net ; tag = 13579 

From : sip : interUEtransf er@sccasl . homel .net ; tag=2255 

Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 

Allow: 

Event: refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 



25-26. SIP 200 OK response (UE-1 to SCC-AS) 

The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 
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A.7.4 Controllee UE releases media 



UE-1 




UE-2 






Intermediate 
IM CN entities 



sec 

AS 



-Collabarative session control 1 

Media-A between UE-1 and Remote UE' 



■Media-B between UE-2 and Remote UE- 



1. re-INVITE- 



14. 200 (OK)- 
—15. ACK — 



-2. re-INVITE- 
-3, re-INVITE- 
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— 7, ACK — 



9. re-INVITE 

c=UE-1 
- Media-A - 
c=UE-2 
Media-B=0 



10. re-INVITE 
c=UE-1 
— Medla-A — 
c=UE-2 
Media-B=0 
11.200 (OK) 
_c= Remote Party_ 
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Medla-B=0 



12.200 (OK) 
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Media-A 
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-16. ACK- 
-17. ACK- 
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I 



Media-A between UE-1 and Remote UE- 



Remote 
UE 



Figure A.7.4: Controllee UE releases media 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

It is assumed that UE-I is controller UE having collaborative session control, a user has a multimedia session on his 
device UE-I with voice (Media A) and UE-2(ControUee UE) video (Media B) media flows. Subsequently, the UE-2 
(Controllee UE) removes the media B flow that is active on the remote UE. 

1-2. SIP re-EVVITE request (UE-2 to SCO AS through IM CN subsystem entities) 

A UE-2 wants to release media B active on the remote UE. For this purpose the UE-2 sends a SIP re-INVITE 
request to the SCC AS through the IM CN subsystem entities. 

3. SIP re-INVITE request (from SCC-AS to intermediate IM CN subsystem entities) - see example in 
table A.14.4-3 

The SCC AS sends SIP re-INVITE request to controller UE, UE-1 to inform that the controUee UE wants to 
release one media, and SCC AS would like to add this media back to the controller UE. 
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Table A.7.4-3: SIP re-INVITE request (SCC AS to controller UE) 



INVITE <sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted-Identity: "John Doe" <sip:user3_public3@home3 .net> 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require : 

Contact: <sip: user3_public3@home3 . net > ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 

t=0 

m=audio 5555 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 PCMU/90000 

m=video 3 000 RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb: ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermediate IM CN subsystem entities to controller UE, UE-1) 

5. SIP 200 (OK) response (controller UE, UE-1 to intermediate IM CN subsystem entities) - see example in 
table A.7.4-5 

In this case, the controller UE does not want to add this media on itself, but Uke to delete this media within the 
collaborative session. The controller UE cknowledges the SIP re-lNVlTE request by sending SIP 200 (OK) 
response to the SCC AS with the port number set to zero for this media. 

Table A.7.4-5: SIP 200 (OK) (controller UE to SCC AS) 



SIP/2.0 200 OK 
Via : 
From : 
To : 

Call-ID: 
Cseq : 

Contact: <sip: userlpubliciohomel . net> ; gr=urn:uuid: f 81d4fae-7dec-lld0-a765- 

0a0c4 3 t Gbr4> ; +g . 3gpp . iut -controller 
Allow : 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb :: CCC : ddd 
S=- 

c = IN IP6 5555 : :aaa:bbb: :ccc:ddd 

t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/9000 



6. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 
7-8.SIP ACK (SCC AS to controller UE) 

9. SIP re-EWITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.7.4-9 

The SCC AS sends a SIP re-INVITE request to update the remote leg that the media B is released. 
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Table A.7.4-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : user3public3@home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r2 . 12 
Max- Forwards : 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted-Identity: "Jake" <sip:userl_publicl@homel .net> 

Privacy: none 

From : <sip : userl_publicl@homel . net > ; tag=17182 8 
To: <sip : user3_public3®home3 . net> ; tag = 66666 
Call -ID: Cb0 3a0s09a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userlpubliclohomel . net > ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c43t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
ontent-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 
t=0 

m=audio 5555 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddd 

a=rtpmap:97 PCMU/90000 

m=video RTP/AVP 98 

C=IN IP6 4444 : :aaa:bbb:CCC:ddd 

a=rtpmap:98 MPV/90000 



10. SIP re-EVVITE request (intermediate EM CN subsystem entities to remote HE) 

11. SIP 200 (OK) response (remote HE to intermediate EM CN subsystem entities) - see example in 
table A.14.4-11 

The remote US sends a SIP 200 (OK) with an SDP offer containing Media A and Media B information. 
Table A.7.4-11 : SIP 200 (OK) (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact: <sip: user3 j>ublic3@home3 .net>; gr=urn:uuid: f 81d4fae-7dec-lld0-a765-00a0c67t6br4> 
Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb :: ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: : ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/9000 



12. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 
13-14. SIP 200 (OK) response (SCC AS to UE-2 through EM CN subsystem entities) 

The SCC AS sends a 200 (OK) response. 
15-16. SIP ACK request (controllee UE to SCC AS) 
17-18. SIP ACK request (SCC AS to remote UE) 
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A.7.5 Controllee UE modifies media on itself 



Media-A between UE-1 and Remote UE- 




SCCAS 



Media-B between UE-2 and Remote UE- 



2. re-INVITE_ 
Media-B 

3. re-INVITE 
c=UE-1 
Media-A - 
c=UE-2 
Media-B 
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Media-B between UE-2 and Remote UE- 
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Figure A.7.5: Controliee UE modifies media on itself 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-2 (Controllee 
UE) modifies the media B flow that is active on the remote UE. 

1. SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities)- see example in table A.7.5-1 

UE-2 sends a SIP re-lN VITE request towards the remote UE containing Media B using SDP offer. 
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Table A.7.5-1 : SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities) 



INVITE <sip:userR_publicl®homel.net;gr=urn:uuid: f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6> SIP/2 .0 
Via : SIP/2 . 0/UDP [4444: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Asserted- Identity : "John Doe2" <sip : userl_public2@homel . net> 
P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 

To: Call-ID: 
Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8642; port-s=7531 

Contact: <sip: userl_public®homel . net> ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 

00a0c67t6br4>Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, 

NOTIFY 

Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa : bbb : CCC : ddd 
S=- 

c=IN IP6 4444 :: aaa : bbb : CCC : ddd 

t = 

m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-EWITE request (intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS according to 
standard IMS procedure. 

3. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities) - see example in table A.7.5-3 

The SCC AS sends a SIP re-INVITE request to the remote UE through the intermediate IM CN subsystem 
entities containing Media A and Media B information in SDP offer. 
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Table A.7.5-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userRpubliclOhomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl.homel.net;branch=z9hG4bK240a48.12 
Max-Forwards: 70 
Route : 

P- Asserted- Identity: 
P- Access -Network- Info : 
Privacy: 
From : 
To : 

Call-ID: 
Cseq : 
Require : 
Proxy-Require : 
Supported : 
Security-Verif y : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 : : aaa :bbb : ccc : ddd 

s=- 

t = 

m=audio 2222 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddda=rtpmap:97 MPV/90000 

m=video 4444 RTP/AVP 98 

c=IN IP6 4444 :: aaa ibbb: ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermedia IM CN subsystem entities to remote UE) 

5. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.5-5 

The remote EU sends a an SIP 200 (OK) response with SDP answer. 

Table A.7.5-5: SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK240f 26 . 3 , SIP/2. 0/UDP 
scscf 2 .homel.net ;branch=z9hG4bK332d25 .1, SIP/2 . 0/UDP 
scscf 1 .homel .net;branch=z9hG4bK332d25 .2, SIP/2 . 0/UDP 
sccasl .homel .net;branch=z9hG4bK240a48 . 12 

From: 

To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



6. SIP 200 (OK) response (intermediate EM CN subsystem entities to SCC AS) 

7-8. SIP ACK request (SCC AS to the remote UE through intermediate IM CN subsystem entities) 
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The sec AS sends an SIP ACK request to the remote UE through the intermediate IM CN subsystem entities. 

9. SIP 200 (OK) response (SCC AS to intermediate EM CN subsystem entities) - see example in table A.7.5-9 

The SCC AS sends a SIP 200 (OK) response containing Media B information and send it to UE-2 through the 
intermediate IM CN subsystem entities. 

Table A.7.5-9 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sccasl . homel .net ;branch=z9hG4bK240f 42 . 22 , 

From: 

To: 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-2) 

11-12. SIP ACK request (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

UE-2 sends a SIP ACK request to the intermediate IM CN subsystem entities which is terminated by the SCC 
AS. 



A. 7. 6 Remote UE adds new media on controllee UE 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and video (Media B) media flows. Subsequendy, the remote UE adds the media B 
flow. In this scenario it is assumed that the controller UE, UE-1 automatically initiates the addition of the new media on 
UE-2 (Controllee) without first alerting the user and sends a SIP REFER request prior to sending back a SIP 200 (OK) 
response to the SIP re-INVITE request. 
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Figure A.7.6: Remote UE add new media on Controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SIP re-INVITE request (remote UE to intermediate EM CN subsystem entities) - see example in 
table A.14.6-1 



ETSI 



3GPP TS 24.337 version 1 0.8.0 Release 10 1 47 ETSI TS 1 24 337 V1 0.8.0 (201 3-07) 



The remote UE sends a SIP re-INVITE request towards the controller UE (UE-1) indicating media B is to be 
added in SDP offer. 

Table A.7.6-1 : SIP re-INVITE request (remote UE to intermediate IM CN subsystem entities) 



INVITE <sip :userl_publicl@homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : <sip ipcscf 2 . visited2 . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 2 . homel .net ; lr> 

P-Asserted- Identity : "David Fan" <sip : user3_public3@home3 . net> 
P-Access-Network-Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8G42; port-s=7531 

Contact : <sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c6 7t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

C=IN IP6 5555 : :aaa:bbb:ccc:ddd 

t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2-4. SIP re-EWITE request 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to UE-1 via the SCC AS according 
to standard IMS procedure. 

5-6. SIP REFER request (UE-1 to SCC AS through intermediate EM CN subsystem entities) - see example 
in table A.7.6-5 

The controller UE determines to add the new media (Media B) on the controllee UE. The controller UE, UE-1 
sends a SIP REFER request to the SCC AS containing a Refer-To header field containing the GRUU of 
controllee UE, UE-2 and a body parameter containing an m line for audio set to and an m line for video with 
the port number set to the port number of the video media line from the SDP offer in the SIP re-lNVlTE request 
from the remote UE. The SIP REFER request also includes a Target-dialog header field containing the details of 
the dialog for the existing session between the controller UE, UE-1 and the remote UE. 
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Table A.7.6-5 SIP REFER request (UE-1 to SCO AS) 



REFER sip: interUEtransferSsccasl .homel .net SIP/2.0 
Via : 

To : sip : interUEtransf erOsccasl . homel . net 

From : sip : userl_publicl®homel . net ; tag=34 719 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Refer- To : <sip : userl_public2®home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765 - 

00a0c91e6bf 6?body=m%3Daudio%2 00%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 04444%2 0RTP%2FAVP%2098> 
Require: target-dialog 

Target -dialog: cb03a0s09a2sdfglkj 490333 ; remote- tag=13579 ; local- tag=24680 
Ref erred-By : sip : userl_publicl@homel . net 

Contact : <sip :userl_publicl®homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g. 3gpp . iut- controller 
Allow: 

Accept : message/sipf rag 
Content-Length: 



7-8. SIP 202 (Accepted) response 

The SCC-AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

9-10. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example 
in table A.7.3.2-5 

The SCC AS sends a SIP NOTIFY request to UE-I to notify impUcit subscription to the SIP REFER request 
results. 

Table A.7.3.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip :userl_publicl@homel . net ; gr=urn :uuid: f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_publicl®homel . net ; tag=34719 

From : sip : interUEtransf er@sccasl . homel .net ; tag=2255 

Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : <sip:user3 j>ublic3@home3 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 

Allow: 

Event: refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



11-12. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC 
AS. 

13-14. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities)-see example 
m table A.7.6-13 

The controller UE responds to the SIP re-INVITE request in step 4. 
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Table A.7.6-13: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34.3, SIP/2. 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 . 0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r4 . 12 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 
Allow: 

Accept: application/sdp ; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 : : aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 3333 : :ccc:ddd:aaa:bbb 
t=0 

m=audio 8888 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



15-16. SIP ACK (SCC AS to UE-1 through intermediate EM CN subsystem entities) 

17. SIP INVITE request (SCC AS to intermediate EM CN subsystem entities)-see example in table A.7.6-15 

NOTE 2: This SIP INVITE request can be sent as soon as the SIP REFER request is received. 

The SCC AS sends a SIP INVITE request towards UE-2 through the intermediate IM CN subsystem entities 
indicating Media B information in SDP offer. 

Table A.7.6-17: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user l_public2@homel .net ; gr=urn :uuid: 2ad892 0e-48a5-4a74 -8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccasl . homel .net ;branch=z9hG4bKnas34r2 . 12 
Max- Forwards : 70 

Route : <sip : termOscscf 1 .homel .net ; lr>, <sip:pcscf 1 . visitedl .net : 7538 ; Ir ; comp=sigcomp> 
P-Asserted-Identity : "John Doe" <sip:user3 j>ublic3@home3 .net> 
Privacy: none 

From: <sip:user3 j>ublic3@home3 .net > ; tag=171828 
To: <sip:userl j)ublic2®homel . net> 
Call-ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Referred-By: sip:userl_publicl@homel .net 

Contact : <sip :user3_public3@home3 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content-Type: application/sdp 
Content -Length : (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 4444 : :bbb: aaa: ccc: ddd 

t = 

m=audio RTP/AVP 97 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18. SIP INVITE request (intermediate IM CN subsystem entities to UE-2) 

19. SIP 200 (OK) response (UE-2 to intermediate EM CN subsystem entities) 

UE-2 responds with a SIP 200 (OK) response containing the SDP answer. 



- see example in table A.7.6-19 
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Table A.7.6-19: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34.3, SIP/2. 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 . 0/UDP 

sccasl .homel .net ;branch=z9hG4bKnas34r2 . 12 
From : 

To : <sip : userl_public2@homel . net> ; tag=237674 
Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : <sip :userl_public2®homel . net ; gr=urn :uuid: 2ad892 0e-4 8a5-4a74 - 8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel " 

Allow: 

Accept: application/sdp; 
Content-Type : application/sdp 
Content -Length: (...) 

v=0 

0=- 2987933300 2987933300 IN IP6 4444 : : aaa :bbb : CCC : ddd 
s=- 

C=IN IP6 4444 :: aaa :bbb: CCC : ddd 
t = 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SEP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
21-22. SIP ACK (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

23. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.6- 
23 

In response to the SIP re-INVITE from the remote UE, the SCC AS sends a SIP 200 (OK) response containing 
the SDP answer towards the remote UE through IM CN subsystem entities, which includes Media A and Media 
B information. 

Table A.7.6-23: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scscf2 .visited2 .net ;branch=34qtrada3333 . 22 , SIP/2 . 0/UDP 
pcscf2 .visited2 .net;branch=34qtrada5454 . 12, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa :bbb : ccc : ddd 

s=- 

t=0 

m=audio 8888 RTP/AVP 97 

c=IN IP6 3333 : :ccc:ddd:aaa:bbb 

a=rtpmap:97 PCMU/8000 

m=video 6666 RTP/AVP 98 

c=IN IP6 4444 : :bbb: aaa: ccc: ddd 

a=rtpmap:98 MPV/90000 



24. SIP 200 (OK) response (intermediate IM CN subsystem entities to remote UE) 
25-26. SIP ACK (remote UE to SCC AS through mtermediate EM CN subsystem entities) 
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The remote UEsends a SIP ACK request to the intermediate IM CN subsystem entities which terminated by the 
sec AS. 

27-28. SIP NOTIFY request (from SCC AS to controller UE, UE-1) 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status if the 
inter-UE transfer. 

Table A.7.6-27: SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: 

To: sip:userl j>ublicl@homel .net ; tag=34 719 

From: sip : interUEtransf er@sccasl . homel .net ; tag=2255 

Call-ID: 

CSeq: 

Max- Forwards : 
P-Asserted- Identity: 
Require : 

Contact : <sip:user3 j>ublic3@home3 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type : message/sipf rag; version=2 . 
Content -Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s=- 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 



29-30. SIP 200 (OK) response (from controUer UE to SCC AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 
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A.7.7 Remote UE releases media on the controller UE 




Intermediate IM 
CN entities 



sec AS 



Coiiabarative session controi 1 

I 

Media-A between UE-1 and Remote UE- 



4. re-iNViTE 
c= Re mote UE- 
i\/ledia-A=0 



5. 200 (OK) 
- c=UE-1 - 
i\/ledia-A=0 



iVIedia-B between UE-1 and Remote UE — 

1. re-iNViTE 

I c= Re mote UE_ 

' i\/ledia-A=0 
iVledia-B 

2. re-iNViTE 
_c=Remote UE 

i\/iedia-A=0 
iViedia-B 

3. re-iNViTE 
I— c= Remote UE— 

i\/iedia-A=0 



8. ACK- 



6. 200 (OK) 
- c=UE-1 - 
i\/iedia-A=0 

— 7. ACK — 

9. 200 (OK) 

c=UE-1 
-i\/iedia-A=0- 
c=UE-2 
iViedia-B 



10.200 (OK) 

c=UE-1 
- iViedia-^O - 
c=UE-2 
iViedia-B 



-11. Aci<- 



-12. Aci<- 



■Coiiabarative session controi- 



I 

-iViedia-B between UE-2 and Remote UE- 



Remote UE 



Figure A.7.7: Remote UE releases media on thie controller UE 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SIP re-INVITE request (Remote Party to intermediate EM CN subsystem entities) - see example in 
table A.14.7-1 

The remote UE sends a SIP re-INVITE request towards the controller UE (UE-1) indicating Media A is to be 
removed using SDP offer. If Media B is to be removed, the SIP re-INVITE request wiU send to controUee UE 
(UE-2). 
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Table A.7.7-1 : SIP re-INVITE request (Remote UE to intermediate IM CN subsystem entities) 



INVITE <sip:userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - OaOc91e6bf 6> SIP/2 .0 
Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 

P-Asserted- Identity : "David Fan" <sip : userR_publicl@homel . net> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec -agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : ddd 
S=- 

c = IN IP6 5555 : :aaa:bbb:CCC:ddd 

t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-EWITE request (intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the re-INVITE request to the SCC AS according to standard 
IMS procedures. 

3. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities) - see example in table A.7.7-3 

The media B is not removed, but the SCC AS set the port of the media B to 0, and forwards it towards 
intermediate IM CN subsystem entities. 
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Table A.7.7-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r4 . 12 
Max-Forwards: 70 

Route : <sip : termOscscf 2 . homel . net ; lr> 

P- Asserted- Identity : 

P- Access -Network- Info : 

Privacy: 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require ; 
Security-Verif y : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio RTP/AVP 97 
a=rtpmap: 97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the controller UE according to 
standard IMS procedure. 

5. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.7-5 

UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.7.7-5: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

sccasl .homel .net;branch=z9hG4bKnas34r4 . 12 
From: 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : <sip :userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g. 3gpp . iut- controller 
Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: eee : fff : aaa : bbb 
s=- 

C=IN IPS 3333 : :eee:fff :aaa:bbb 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
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7-8. SIP ACK (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to the controller UE through the intermediate IM CN subsystem entities. 

9. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.7-9 

The SCC AS sends a SIP 200 (OK) response with an SDP answer indicating Media A is removed to the 
intermediate IM CN subsystem entities 

Table A.7.7-9: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel .net ;branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scsf2 .visited2 .net;branch=3q5qef sdr62233 .22, SIP/2 . 0/UDP 
pcscf2 .visited2 .net;branch=3q5qef sdr62245 . 12, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : <sip :userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g. 3gpp . iut- controller 
Allow: 

Accept: application/sdp ; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 3333 : :aaa:bbb:ccc:ddd 
t=0 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
c=IN IP6 4444 :: aaa: bbb: ccc: ddd 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to remote UE) 

11-12. SIP ACK (remote UE to SCC AS through intermediate IM CN subsystem entities) 

The remote UE sends a SIP ACK request to UE-1 through the intermediate IM CN subsystem entities which is 
terminated by the SCC AS. 



A.8 Signalling flows for collaborative session of 
participants of different subscriptions 

A.8.1 Introduction 

This subclause demonstrates the flows for collaborative sessions of participants of diffierent subscriptions. 

A.8. 2 Signalling flow for controller UE initiated media transfer from 
controller UE to controllee UE belonging to different 
subscriptions under the same operator 

In the example flow of figure A.8. 2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. UE- 
1 and UE-2 belong to different subscribers. UE-1 decides to transfer video media to UE-2 and keep the collaborative 
session control. 
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HPLMN of the local UE participating In session 
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Figure A.8.2-1 : Signalling flow for controller UE initiated media transfer from controller UE to 
controllee UE belonging to different subscriptions under the same operator 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. UE-l is in session with lJE-3 

There is a multimedia session comprising audio and video media between UE-l and remote UE-3 anchored at 
sec AS- 1. 

2. UE-l decides to transfer the video portion of the session from UE-l to UE-2 and keep the collaborative 
session control. 

3-4, SIP REFER request (UE-l to SCC AS-1) - see example in table A.8.2-3 

UE-l sends a SIP REFER request to SCC AS-1 to request the media transfer. 

Table A.8.2-3: SIP REFER request (UE-1 to SCC AS-1) 



REFER sip : interUEtransf erOexample .net SIP/2.0 

Ref er-To : <sip : user2@homel . net ; gr=urn : uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 ?body= 

m%3Daudio%2 00%2 0RTP%2FAVP%97%0Dm%3Dvideo%203 002%20RTP%2FAVP%2 098%2 099> 
Via: SIP/2. 0/UDP [5555: : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7df dsdq 
Max- Forwards : 7 

P-Pref erred-Identity : <sip:userl@homel .net> 
From: <sip :userl@homel .net> ; tag=17182 8 

To: <sip:user2@homel .net ; gr=urn: uuid : f81d4fae- 7dec-lld0 -2222 -222222222222 > 
Call-ID: Asdasd23123366 
Cseq: 4897924 REFER 

Contact : <s ip: user IShomel .net ; gr=urn : uuid : f81d4fae- 7dec-lld0- 1111- 111111111111> 
Referred-by: sip:userl@homel .net 

Accept -Contact : * ; +g. 3gpp. iut- focus /explicit ; require 
Accept: application/sdp, message/sipf rag 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content -Length: 



5. When SCC AS-1 receives the SIP REFER request, SCC AS-1 authorizes the request. 
6-7. SIP 202 (Accepted) response to SIP REFER request (SCC AS-1 to UE-l). 
8-9. SIP NOTIFY request (SCC AS-1 to UE-l) 

SCC AS-1 informs UE-l about the implicit subscription to the SIP REFER request results. 
10-11. SIP 200 (OK) response to SIP NOTIFY request (UE-l to SCC AS-1) 

UE-l confirms the SIP NOTIFY request by sending a SIP 200 (OK) response to the SIP NOTIFY request. 

12-15. SIP INVITE request (SCC AS-1 to UE-2) - see example in table A.8.2-12 

SCC AS-1 sends the SIP INVITE request towards UE-2 to establish a session based on the information provided 
in the SIP REFER request. 
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Table A.8.2-12: SIP INVITE request (SCC AS-1 to UE-2) 



INVITE sip : user2@home2 .net SIP/2.0 




Via: SIP/2. 0/UDP 




Max- Foarwaards : 




From : <sip : interUEtransf erOexample . net > ; tag=387f 


39 


To: <sip : user2@home2 . net ; > 




Call-ID: duie4hr3896 




Cseq: 41 INVITE 




Contact : <sip : sccasl . homel . example . net> ; +g . 3gpp 


iut-focus 


Referred-By: sip : useriohomel . net 




Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, 


REFER, MESSAGE 


Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s=- 

C=IN IP4 123.112.67.87 




t = 




m=audio RTP/AVP 97 




m=video 3002 RTP/AVP 98 99 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





16-19. SEP 200 (OK) response to SIP INVITE request (UE-2 to SCC AS-1) 

UE-2 acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to SCC AS-1. 
20-23. SIP ACK request (SCC AS-1 to UE-2) 

SCC AS-1 sends a SIP ACK request to UE-2. 
24-25. SIP re-INVITE request (SCC AS-1 to UE-1) 

SCC AS-1 sends a SIP re-INVITE request to UE-1 to hold the media to be transferred. 
26-27. SIP 200 (OK) response (UE-1 to SCC AS-1) 

UE-1 acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to SCC AS-1. 
28-29. SIP ACK request (SCC AS-1 to UE-1) 

SCC AS sends a SIP ACK request to UE-1. 
30-32. SIP re-INVITE request (SCC AS-1 to UE-3)- see example in table A.8.2-30 

SCC AS-1 sends a SIP re-INVITE request to the remote UE to update the video media. 
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Table A.8.2-30: SIP INVITE request (SCC AS-1 to UE-3) 



INVITE sip:user3@home3 .net SIP/2.0 
Via : 

To: sip : user3_public3®home3 . net ; tag = 66666 
From: sip : interUEtransf erOexample . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : useriohomel . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123 .45.67.89 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
c=IN IP4 145.23.77.88 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



33-35. SIP 200 (OK) response to re-EWITE request (UE-3 to SCC AS-1) 

After successful media update, UE-3 sends a SIP 200 (OK) response towards SCC AS-1. 
36-38. SIP ACK request (SCC AS-1 to UE-3) 

SCC AS-1 sends a SIP ACK request to remote UE-3. 
39-40. SIP re-INVITE request (SCC AS-1 to UE-1) 

The SCC AS sends a SIP re-INVITE request to UE-1 to update the media in UE-1. 
41-42. SIP 200 (OK) response (UE-1 to SCC AS-1) 

UE-1 acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to SCC AS-1. 
43-44. SIP ACK request (SCC AS-1 to UE-1) 

The SCC AS sends a SIP ACK request to UE-1. 
45-48, SIP re-EWITE request (SCC AS-1 to UE-2) 

SCC AS-1 sends a SIP re -INVITE request to UE-2 to activate the video media components. 
49-52. SIP 200 (OK) response (UE-2 to SCC AS-1) 

UE-2 acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the SCC AS. 
53-56. SIP ACK request (SCC AS-1 to UE-2) 

The SCC AS sends a SIP ACK request to UE-2. 
57-58. SIP NOTIFY request (SCC AS-1 to UE-1) 

SCC AS-1 informs the UE-1 that the action triggered by the SIP REFER request was successfully completed. 
59-60. SIP 200 (OK) response to SIP NOTIFY request (UE-1 to SCC AS-1) 
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UE-1 confirms the SIP NOTIFY request by sending a SIP 200 (OK) response to the SIP NOTIFY request. 



A.9 Signalling flows for for establishment of a 
collaborative session during session setup 

A.9.1 Introduction 

The signalHng flows in this subclause demonstrate how a UE-1 can estabhsh a Collaborative Session during originating 
and terminating session setup. 

A.9. 2 Collaborative session establishment upon originating 
session setup 

In the example flow at the figure A.9.2-1, UE-1 wants to establish a collaborative session without the pre-requisite of 
having an IMS session established. The UE-1 wants to setup a collaborative session with audio media flow in UE-1 and 
video media flow in UE-2, and wants to control the collaborative session through UE-1. 
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UE-1 



UE-2 



SCC-A 



Intermediate IM CN subsystem 
entities 



1. iNViTE UE-3 



2. iNViTE UE-3 



3. iNViTE UE-2 



4j iNViTE UE-2 



5.^00 OK to UE-2 



6.200 OKto iNViTE UE-2 



7. iNViTE UE-3 



10. 200 OKto iNViTE UE-3 



11.200 OKto iNViTE UE-3 



12.200 OK to iNViTE UE-3 



13. ACK 



14. ACK 



15. ACK 



17. SiPre-iNViTEUE-2 



18. SiPre-iNViTEUE-2 



19. 200 OKto SiP re-iNViTE UE-2 



20. 200 OKto SiP re-iNViTE UE-2 



21. ACK 



22. ACK 



I 23. iViedia (audio) 



24. iViedia path (video) 



UE-3 



8. iNViTE UE-3 



9.200 OKto iNViTE UE-3 



16. ACK 



Figure A.9.2-1 : Signaiiing fiow for establishment of collaborative session upon originating IMS 

session 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 
1-2. SIP INVITE request (UE-1 to SCC AS) - see example in table A.9.2-1 
The UE-1 sends SIP INVITE request to SCC AS to setup the collaborative session. 
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Table A.9.2-1 : SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE SIP: user3®examplel . net ; SIP/2.0 

Via: SIP/2. 0/UDP 192 . . 2 . 5 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : sip :pcscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 .homel .net ; lr> 
P- Preferred- Identity : <sip :uesrl@examplel .net> 

P-Access-Network-Info : 
Privacy: none 

From: <sip : userlOexamplel . net> ; tag=171828 
To: <sip : user3@examplel . net > 
Call -ID : Cb0 3a0s0 9a2sdfglkj4 902 3 7 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userlOexamplel . net ; gr= urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 
s = 

t = 

c=IN IP4 192.0.2.5 

m=audio 49170 RTP/AVP 8 3 

b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=video 9 RTP/AVP 98 
c=IN IP4 0.0.0.0 

a=3gpp . iut . control lee sip :user2@example2 . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



SDP: The first media stream (audio) will be terminated by UE-1 of which the IP address is indicated in the c-line in 
the SDP. 

The port number of the remote side, i.e. UE-3 for the video media is currently not known to UE-1, therefore the 
port number for the video media stream is set to the discard port number "9". 

3-4. SIP EWITE request (SCC AS to UE-2) - see example in table A.9.2-3 

Upon receiving the SIP INVITE request, the SCC AS sends a SIP INVITE request to UE-2 to establish the 
media between UE-2 and the remote UE-3. 

Table A.9.2-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip :user2@examplel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 ; SIP/2 . 
Via: 

Record- Route : sip:sccasl. homel . example .net 

To: <sip : user2@examplel . net > 

From : sip : userlOexamplel .net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted-Identity : sip:userl@examplel .net 
Require : 

Contact : <sip : userlOexamplel .net ; gr= urn : uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 

Allow: 

Content -Type : application/sdp 
Content-Length: (...) 
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v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 
s = 

t = 

C=IN IP4 192.0.2.5 
a=creq: ccap-vO 
m=audio RTP/AVP 8 3 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 

m=video 9 RTP/AVP 98 

C=IN IP4 0.0.0.0 

b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



5-6. SIP 200(OK) response to SIP INVITE request (UE-2 to SCC AS) - see example in table A.9.2-5 
Table A.9.2-5: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 
Via : 

To : <sip : user2@examplel . net > ; tag=xyzwv 
From: <sip :userl®examplel . net > ; tag=171828 
Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : sip :user2@examplel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 
Allow: INVITE, PRACK, UPDATE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 192.0.2.5 

s = - 
t = 

m=audio RTP/AVP 8 3 
m=video 13 RTP/AVP 98 
a=inactive 

C=IN IP4 145.23.77.88 
b=AS : 75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 



SDP: The connection information now indicates the IP address of UE-2. 
7-8. SIP INVITE request (SCC AS to UE-3) 

The SCC AS sends the SIP INVITE request towards the remote UE-3 containg the SDP information of UE-1 and 
UE-2. 

9-12. SIP 200 (OK) reponse to SIP INVITE request(UE-3 to UE-1) 

UE-3 acknowledges the SIP INVITE request by sending SIP 200 (OK) response with the SDP answer to UE-1. 
13-16. SEP ACK request (UE-1 to UE-3) 

UE-1 sends SIP ACK request to the remote UE. 
17-18. SIP re-INVITE request (SCC AS to UE-2) 

SCC AS-2 sends SIP re-INVITE request to UE-2 to update the media in UE-2. 
19-20. SIP 200 (OK) response to SIP re-EVVITE request (UE-2 to SCC AS) 
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The UE-2 confirms the SIP re-INVITE request by sending SIP 200 (OK) response to SCC AS. 
21-22. SIP ACK request (SCC AS to UE-2) 

SCC AS sends SIP ACK request to the remote UE. 
23-24. Media path: 

The audio media is between controller UE-1 and remote UE-3, and the video media is estabhshed between 
controUee UE-2 and the remote UE. The collaborative session control is in the controller UE-1. 

A.9.3 Collaborative session establishment upon originating 
session setup with forked responses 

In the information flow at the figure A.9.2a-1, UE-1 wants to estabUsh a collaborative session without the pre-requisite 
of having an IMS session established. The UE-1 wants to setup a collaborative session with audio media flow in UE-1 
and video media flow in UE-2, and wants to control the collaborative session through UE-1. 

The SIP INVITE request is forked to the remote party. This flow assumes that the second Remote UE accepts the call. 



ETSI 



3GPP TS 24.337 version 10.8.0 Release 10 



165 



ETSI TS 124 337 VI 0.8.0 (2013-07) 



sec- AS 



1. INVITE 



Intermediate IM CN 
subsystem entities 



2 . INVITE 



3. INVITE 



4. INVITE 



5. 18310 INVITE 



6 .183 to INVITE 



7. INVITE 



10a. 183 to INVITE 



11 a. 183 to INVITE 



r 



12a .183 to INVITE 



13a . UPDATE 



14a. UPDATE 



15a. 200 OK to UPDATE 



16a. 200 OK to UPDATE 



10b. 183 to INVITE 



lib. 183 to INVITE 



12b .183 to INVITE 



13b. Intercept and save the 
SIP 183 when determining 
that the session is forl<ed 



17. 200 OK to 



18 . ACK 



15 .200 OK to INVITE 



16 . 200 OK to INVITE 



4 



INVITE 



19 . ACK 



20. ACK 



22. UPDATE (saved rest 



23 . UPDATE (saved response 



24. 200 OK to UPDATE 



25 .200 OK to UPDATE 



26. 200 OK to INVITE 



27 . 200 OK to INVITE 



28 . ACK 



29 . ACK 



30 .CANCEL 



31 . CANCEL 



34.200 OK to CANCEL 



35. 200 OK to CANCEL. 



Media (audio) 



Media (video) 



8a. INVITE 



8b. INVITE 



9a. 183 to INVITE 



9b. 183 to INVITE 



14 . 200 OK to INVITE 



21 ACK 



nse in step 9b) 
1 step 9b) 



32 . CANCEL 



33.200 OK to CANCEL 



4 



ETSI 



3GPP TS 24.337 version 1 0.8.0 Release 10 1 66 ETSI TS 1 24 337 V1 0.8.0 (201 3-07) 

Figure A.9.3-1 : Signalling flow for establishment of collaborative session upon originating IMS 

session with forked response 

NOTE: For clarity, the SIP 100 (Trying), SIP PRACK requests to 183 (Session Progress) responses and SIP 200 
(OK) responses to SIP PRACK requests are not shown in the signalling flow. 

1-2. SIP INVITE request (UE-1 to SCC AS) - see example in table A.9.3-1 

The UE-1 sends SIP INVITE request to SCC AS to setup the collaborative session. 

Table A.9.3-1 : SIP INVITE request (UE-1 to intermediate IIUI CN subsystem entities) 



INVITE SIP: user3@examplel.net; SIP/2.0 

Via: SIP/2. 0/UDP 192 . . 2 . 5 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : sip : pcscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 . homel . net ; lr> 
P-Pref erred-Identity : <sip:uesrl@examplel .net> 
P -Access -Network- Info : 
Privacy: none 

From: <sip : userl@examplel . net > ; tag=171828 
To: <sip : user3@examplel . net> 
Call -ID : Cb0 3a0s09a2sdfglkj4 90237 
Cseq: 12 7 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha- 1- 96 ; spi=87654321 ; portl=7531 
Contact : <sip:userl@examplel .net ;gr= urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 
s= 

t = 

C=IN IP4 192.0.2.5 

a=creq: ccap-vO 

m=audio 4 9170 RTP/AVP 8 3 

b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 
m=video 9 RTP/AVP 98 
c=IN IP4 0.0.0.0 

a=3gpp. iut . controllee SIPURI sip :user2@example2 .net ; gr=urn:uuid: f 81d4fae-7dec-lld0-a765- 

00a0c91e6bf6 
b=AS:75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



SDP: The first media stream (audio) will be terminated by UE-1 of which the IP address is indicated in the c-line in 
the SDP header. The second media stream (video) will be terminated by UE-2. 

The port number of the UE-2 for the video media is currently not known to UE-1, therefore the port number for 
the video media stream is set to the discard port number "9". 

3-4. SIP EWITE request (SCC AS to UE-2) - see example in table A.9.2-3 

Upon receiving the SIP INVITE request, the SCC AS sends a SIP INVITE request to UE-2 to establish the 
media between UE-2 and the remote UE-3. 
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Table A.9.3-3: SIP INVITE request (SCO AS to intermediate IM CN subsystem entities) 



INVITE sip:uesr2@examplel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 ; SIP/2 . 
Via : 

Record- Route : sipisccasl. homel . example .net 

To: <sip : user2@examplel . net> 

From: sip : user l@examplel .net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted-Identity : sip:userl@examplel .net 
Require : 

Contact : <sip :userl@examplel .net ; gr= urn ;uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 

s= 

t=0 

m=audio RTP/AVP 8 3 
m=video 9 RTP/AVP 98 
C=IN IP4 0.0.0.0 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



5-6. SIP 183 (Session Progress) response to SIP INVITE request (UE-2 to SCC AS) 

The UE-2 responds with SIP 183 (Session Progress) response containing the SDP answer of UE-2. 

Table A.9.3-5: SIP 183 (Session Progress) response (UE-2 to Intermediate IIUI CN subsystem entities) 



SIP/2.0 183 Session Progress 
Via : 

Record-Route : sip : sccasl . homel . example . net 
To : <sip : user2@examplel . net > ; tag=edf cb 
From : sip : user lOexamplel .net ; tag=acegi 
Call-ID: 
CSeq: 

Max- Forwards : 

P-Asserted-Identity : sip:userl@examplel .net 
Require : 

Contact : <sip :userl@examplel .net ; gr= urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 
s= 

t = 

m=audio RTP/AVP 8 3 
m=video 13 RTP/AVP 98 
a=inactive 

C=IN IP4 145.23.77.88 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



7. SIP INVITE request (SCC AS to Intermediate EM CN subsystem entities) - see example in table A.9.3-7 

The SCC AS sends the SIP INVITE request, which contains the SDP information of UE-1 and UE-2, towards 
the Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE. 

8a. SIP INVITE request (Intermediate IM CN subsystem entities to UE-3) 

Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, determine that the SIP INVITE 
request should be forked, and send the SIP INVITE request to UE-3. 
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8b. SIP INVITE request (Intermediate IM CN subsystem entities to UE-4) 

Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, determine that the SIP INVITE 
request should be forked, and send the SIP INVITE request to UE-4. 

9a-10a. SIP 183 (Session Progress) response to SIP INVITE request (UE-3 to SCC AS) 

The remote UE-3 responds with SIP 183 (Session Progress) response containing the SDP answer of the remote 
UE-3. 

Table A.9.3-9a: SIP 183 (Session Progress) response (UE-3 to Intermediate IIUI CN subsystem entities) 



SIP/2.0 183 Session Progress 
Via : 

Record-Route : sip : sccasl . homel . example . net 
To: sip : user3®examplel . net ; tag = 66666 
From: sip : user l@examplel .net ; tag=acegi 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : <sip :user3@examplel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.1.3.9 

s= 
t= 

c=IN IP4 192 .1.3.9 
a=creq : ccap-vO 
m=audio 3370 RTP/AVP 8 3 
b=AS : 25 . 4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

m=video 4390 RTP/AVP 98 

C=IN IP4 192.1.3.9 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



lla-12a. SIP 183 (Session Progress) response to SIP INVITE request (SCC AS to UE-1) 

The SCC AS responds UE-1 with SIP 183 (Session Progress) response containing the SDP answer of UE-3. 

13a-14a. SIP UPDATE request (SCC AS to UE-2) - see example in table A.9.3-9a 

The SCC AS sends a SIP UPDATE request to UE-2 based on the SIP 183 (Session Progress) response fromUE- 
3. 
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Table A.9.3-13a: SIP UPDATE request (SCC AS to UE-2) 



UPDATE sip:user2@examplel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

Record-Route : 

To: sip : user2@examplel . net ; tag=edfcb 
From: sip : user l@examplel .net ; tag=acegi 
Call-ID: 
CSeq: 

Max- Forwards : 

P-Asserted-Identity : "remote user" sip:user3@examplel .net 
Require : 

Contact : sip :user3@examplel .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 192.0.2.23 

s=- 
t=0 

m=audio RTP/AVP 8 3 
m=video 4390 RTP/AVP 34 
a= sendrecv 
c=IN IP4 192.0.2.23 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



15a-16a. SIP 200 (OK) response to SIP UPDATE request (UE-2 to SCC AS) 

UE-2 sends the SIP 200 (OK) response to SIP UPDATE request towards the SCC AS. 

9b-10b. SIP 183 (Session Progress) response to SIP INVITE request (UE-4 to SCC AS) 

The remote UE-4 responds with SIP 183 (Session Progress) response containing the SDP answer of the remote 
UE-4. 
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Table A.9.3-9b: SIP 183 (Session Progress) response (UE-4 to Intermediate IIUI CN subsystem entities) 



SIP/2.0 183 Session Progress 
Via : 

Record-Route : 

To : sip : userSOexamplel . net ; tag=77777 
From: sip : user l@examplel .net ; tag=acegi 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip :user3@examplel .net ; gr=urn ;uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.1.4.8 

s= 
t= 

C=IN IP4 192.1.4.8 
a=creq : ccap-vO 
m=audio 3570 RTP/AVP 8 3 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=video 3580 RTP/AVP 98 

C=IN IP4 192.1.4.8 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



llb-12b. SIP 183 (Session Progress) response to SIP INVITE request (SCC AS to UE-1) 

The SCC AS responds UE-1 with SIP 183 (Session Progress) response containing the SDP answer of UE-4. 

13b. The SCC AS saves the SIP 183 (Session Progress) response when determining that the session is forked 

The SCC AS determines that the call is forked according to step 10a and 10b and saves the SIP 183 message of 
step 10b. 

14-15. SIP 200 (OK) response to the initial SIP INVITE request (UE-4 to SCC AS) 

When the remote UE answers the call, UE-4 sends the SIP 200 (OK) response back to UE-1 via the SCC AS. 
16-17, SIP 200 (OK) response to the initial SIP INVITE request (SCC AS to UE-1) 

The SCC AS sends the SIP 200 (OK) response to UE-1. 
18-19. SIP ACK request (UE-1 to SCC AS) 

UE-1 sends the SIP ACK request to confirm the estabUshment of call to SCC AS. 
20-21. SIP ACK request (SCC AS to UE-4) 

SCC AS sends the SIP ACK request to UE-4. 

22-23. SIP UPDATE request (SCC AS to UE-2) - see example in table A.9.3-22a 

The SCC AS sends to UE-2 a SIP UPDATE request with the saved information in SIP 183 (Session Progress) 
response in step 13b to control the renegotiation of the video media when determining that the UE-4 has 
answered the call. 



ETSI 



3GPP TS 24.337 version 1 0.8.0 Release 10 1 71 ETSI TS 1 24 337 VI 0.8.0 (201 3-07) 

Table A.9.3-22a: SIP UPDATE request (SCC AS to UE-2) 



UPDATE sip:user2@examplel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via : 

Record-Route : 

To: sip : user2@examplel . net ; 

From: sip : user l@examplel .net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted-Identity : "remote user" sip:user3@examplel .net 
Require : 

Contact : sip :user3@examplel .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 192.0.2.23 

s=- 
t=0 

m=audio RTP/AVP 8 3 
m=video 3 580 RTP/AVP 98 
a= sendrecv 
c=IN IP4 192.1.4.8 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



24-25. SIP 200 (OK) response to SIP UPDATE request (UE-2 to SCC AS) 

UE-2 sends the SIP 200 (OK) response towards SCC AS. 
26-27. SIP 200 (OK) response to SIP INVITE request (UE-2 to SCC AS) 

UE-2 sends the SIP 200 (OK) response to the SIP INVITE request in step 4 towards SCC AS. 
28-29. SIP ACK request (SCC AS to UE-2) 

SCC AS sends the SIP ACK request to UE-2. 
30-32. SIP CANCEL request ( Intermediate EM CN subsystem entities to UE-3) 

The intermediate IM CN subsystem entities sends the SIP CANCEL request to UE-3. 
33-35. SIP 200 (OK) response to SIP CANCEL request (UE-3 to Intermediate EM CN subsystem entities) 

UE-3 responds SIP 200 (OK) response to the SIP CANCEL request 
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A.9.4 Collaborative session establishment upon terminating 
session setup 
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Figure A.9.4-1 : Call flows for establishment of collaborative session upon terminating IMS session 

setup using SIP 300 (Multiple Choices) response 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 
1-2. SIP EWITE request (UE-3 to SCC AS) - see example in table A.9.4-1 

The UE-3 sends SIP INVITE request to UE-1 to setup the session. 

Table A.9.4-1: SIP INVITE request (UE-3 to Intermediate IM CN subsystem entities) 



INVITE sip : userlOexamplel . net SIP/2.0 

Via: SIP/2. 0/UDP 192 . . 2 . 5 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 75 31 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 . homel .net ; lr> 
P- Preferred- Identity: <sip :uesr3@examplel . net > 
P- Access -Network- Info: 
Privacy: none 

From: <sip : user3@examplel . net > ; tag=171828 
To: <sip : userloexamplel . net> 
Call- ID: Cb03a0s09a2sdfglkj490237 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : user3@examplel . net ; gr= urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 
s= 

t = 

C=IN IP4 192.0.2.5 

m=audio 49170 RTP/AVP 8 3 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 

m=video 2 8540 RTP/AVP 98 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



3-4. SIP INVITE request (SCC AS to UE-1) - see example in table A.9.4-3 

The SCC AS adds an Accept-Contact header field containing the media feature tag g.3gpp.iut-controller along 
with the explicit parameter to indicate a preference to reach a controller capable UE and also includes the MIME 
type application/vnd.3gpp.iut+xml to indicate that it supports the MIME type and then sends the SIP INVITE 
request to UE-1 to setup the session. 
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Table A.9.4-3: SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities) 



INVITE sip:userl@examplel .net SIP/2.0 
Via : 

Max- Forwards : 
Route : 

P-Asserted-Identity: <sip:uesr3@examplel .net> 
Privacy: none 
From : 
To : 
Cseq : 

Supported : 
Require : 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Accept -Contact : * ; +g . 3gpp . iut- controller; explicit 

Contact : 
Allow : 

Accept: application/sdp; application/3gpp- ims+xml ; application/vnd. 3gpp . iut+xml 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
t= 
c = 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 



5-6. SIP 300 (Multiple Choices) response to SIP INVITE request (UE-1 to SCC AS) see example in 
table A.18.3-5 

The UE-1 responds with SIP 300 (Multiple choices) response to SCC AS including in the body the media 
characteristics (Audio and Video) associated with the contact addresses of UE-1 and UE-2 respectively. 

Table A.9.4-5: SIP 300 (Multiple Choices) response (UE-1 to SCC-AS) 



SIP/2.0 300 Multiple Choices 

Via: 

To: 

From: 

Call-ID: 

CSeq: 

P-Asserted- Identity : sip : userlOexample . net 

Contact : <sip : user l@example .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz> , 

<s ip: user l@example .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> 

Allow: 

Content -Type=applicat ion/vnd. 3gpp. iut+xml 
Content -Length: (...) 



<controlTransf er> 

<activeController=<sip : user l@example .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz?body=m%3Daudio%2049170%20RTP%2FAVP%97%0D>/> 

<controllee=<sip : user lOexample .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6?body=m%3Dvideo%2028540%20RTP%2FAVP%98%0D>/> 
</controlTransf er> 



7-8. SIP ACK request (SCC AS to UE-1) 
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9. sec AS authorizes the request for the collaborative session setup involving lJE-2. 

10-11. SIP 183 (session progress) response to SIP INVITE request (SCC AS to UE-3) 

The SCC AS responds with SIP 183 (session progress) response to UE-3 including an SDP answer based on the 
media types contained in the SIP 300 (Multiple choices) response and containing the discard port number "9" for 
those media lines with "a=inactive". 

Table A.9.4-10: SIP 183 (Session Progress) response (SCC-AS to UE-3) 



SIP/2.0 183 Session Progress 

Via: 

To: 

From: 

Call-ID: 

CSeq: 

P-Asserted- Ident i ty : s ip : user l@example . net 

Privacy: 

Require : 

Supported: 

Contact : <sip : user l@example .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz> 
Allow: 

Content -Type=application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 0.0.0.0 
s= 

t=0 

C=IN IP4 0.0.0.0 
m=audio 9 RTP/AVP 8 3 
a= inactive 

m=video 9 RTP/AVP 98 
a= inactive 



12-13. SIP INVITE request (SCC AS to UE-1)- - see example in table A.9.4-12 

The SCC AS sends the SIP INVITE request to initiate the audio media setup in UE-1. 
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Table A.9.4-12: SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities) 



INVITE sip : userloexample . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via: SIP/2. 0/UDP 192 . . 2 . 5 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 
Route : 

P-Pref erred-Identity: <sip:uesr3@examplel .net> 

P- Access -Network- Info : 
Privacy: none 

From: <sip : user3@examplel . net> ; tag=171828 
To: <sip : userlOexamplel . net > 
Call -ID: Cb0 3a0s09a2sdfglkj4 9023 7 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : user3@examplel . net ; gr= urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 

s = 

t = 

C=IN IP4 192 .0.2.5 

m=audio 49170 RTP/AVP 8 3 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 
m=video RTP/AVP 98 



14-15. SIP INVITE request (SCC AS to UE-2)- - see example in table A.9.4-14 

The SCC AS sends the SIP INVITE request to initiate the video media setup in UE-2. 
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Table A.9.4-14: SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities) 



INVITE sip : userloexample . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP 192 . . 2 . 5 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 
Route : 

P-Pref erred-Identity: <sip:uesr3@examplel .net> 

P- Access -Network- Info : 
Privacy: none 

From: <sip : user3@examplel . net> ; tag=171828 
To: <sip : userlOexamplel . net > 
Call -ID: Cb0 3a0s09a2sdfglkj4 9023 7 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : user3@examplel . net ; gr= urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.5 

s = 

t = 

c=IN IP4 192 .0.2.5 
m=audio RTP/AVP 97 
m=video 28540 RTP/AVP 98 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



20-21. SIP UPDATE request (SCC AS to UE-3)- - see example in table A.9.4-20 

The SCC AS then sends the SIP UPDATE request to UE-3 with the SDP answer of UE-1 and UE-2 received 
in the SIP 183 (session progress) responses. 
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Table A.9.4-20: SIP UPDATE request (SCC AS to Intermediate IM CN subsystem entities) 



UPDATE sip:user3@examplel .net SIP/2.0 
Via : 

To: sip : userSOexample . net ; tag = 66666 
From: sip :userl®example . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userlOexample . net ; gr=urn :uuid: f 81d4f ae- 7dec- Ild0-a765- 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123 .45.67.89 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video 1500 RTP/AVP 98 

c=IN IP4 123.45.67.42 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



22-23. SIP 200 (OK) response to SIP UPDATE request (UE-3 to SCC AS) 

UE-3 sends the SIP 200 (OK) response to the SIP UPDATE request. 

24-25. SIP UPDATE request (SCC AS to UE-1) 

The SCC AS sends the SIP INVITE request to the UE-1 based on the SDP content in the SIP 200 (OK) response 
to the SIP UPDATE request received from UE-3. 

26-27. SIP UPDATE request (SCC AS to UE-2) 

The SCC AS sends the SIP INVITE request to the UE-2 based on the SDP content in the SIP 200 (OK) response 
to the SIP UPDATE request received from UE-3. 

28-29. SIP 200 (OK) response to SIP UPDATE request (UE-1 to SCC AS) 

30-31. SIP 200 (OK) response to SIP UPDATE request (UE-2 to SCC AS) 

32-33. SIP 200 (OK) response to SIP INVITE request (UE-1 to SCC AS) 

When the UE-1 answers the call, it sends the SIP 200 (OK) response to the initial SIP INVITE request. 
34-35. SIP 200 (OK) response to SIP INVITE request (UE-2 to SCC AS) 

When the UE-2 answers the call, it sends the SIP 200 (OK) response to the initial SIP INVITE request. 
36-37. SIP 200 (OK) response to SIP INVITE request (SCC AS to UE-3) 

The SCC AS sends the SIP 200 (OK) response to the UE-3. 
38-39. SIP ACK request (UE-3 to SCC AS) 
40-41. SIP ACK request (SCC AS to UE-1) 
42-43. SIP ACK request (SCC AS to UE-2) 
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A.1 Signalling flows for assignment and transfer of 
control of a collaborative session 

A.1 0.1 Introduction 

The signalling flows in this subclause demonstrate how a UE-1 can transfer control of the collaborative session to UE-2. 

A.1 0.2 Transfer of control of a collaborative session without media 
transfer 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and video (Media B) media flows. The controller UE, UE-1 initiates the transfer of 
collaborative session control to UE-2 without transferring media from UE-1. 



UE-1 




UE-2 









REFER 
Refler-To: "UE-2 
<controlTransferXML MIME body part>" 



-4. 2 02 Accepted- 
fi.NOTIFY 



Intermediate 
IM CN entities 



sec AS 



-Collaborative session control' 



200 OK- 



_ 10. re-INVITE with _ 
contents perflowl, 2 

11. 200 OK 



I Collabarative ses|sion control 

-13.ACK- 

-14. ACK- 



J 6. NOTIFY with ^ip/frag body part with 200_ 
OK 



7. 200 OK- 



2. REFER 
Refer-To: "UE-2 
-<controlTransfer^ 
XML MIME body 
part>" 

h3. 202 Accepted — 

I 5. NOTIFY 



-8. 200 OK- 



9. re-INVITE with 
contents perflowl, 2 



-12.200 OK- 



15. NOTIFY with sip/ 
I frag body part with - 
200 OK 



-18. 200 OK- 



Figure A.1 0.2-1 : Controller UE transfers collaborative session control without transferring media 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 
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1-2. SIP REFER request (controller UE to intermediate EM CN subsystem entities) - see example in 
table A.10.2-1 

It is assumed that UE-1 and UE-2 have the controller UE functionality. The controller UE wants to transfer 
control of the collaborative session to UE-2. 

UE-1 sends a SIP REFER request to the SCC AS containing: 

a) the Refer-To header field SIP URI containing: 

i) TheGRUUof UE2; 

ii) A "body" URI header field containing the <controlTransfer> XML element including the 
<targetController> element set to the GRUU of UE-2. 

b) the Contact header field containing the media feature tag g.3gpp.current-iut-controller set to "passive" 

UE-1 does not include the g.Bgpp.iut-controUer media feature tag in the Contact header field of the SIP REFER 
request as it is indicating to the SCC-AS that it is transferring control of the collaborative session to UE-2. 

Table A.10.2-1 : SIP REFER request (UE-1 to SCC AS) 



REFER sip: interUEtransf erSexample .net SIP/2.0 
Via: 

To : sip : interUEtransf erSexample .net 

From: sip : user l_publicl@homel .net ; tag=13579 

Call-ID: Cb03a0s09a2sdfglkj490333 

CSeq: 93809824 REFER 

Max- Forwards : 7 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel .net> 
Refer-To : <sip :User2_public2@home2 .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a762 - 
00a0c91e6bf 6?body=<controlTransf er> <targetController=<sip : 

user2_public2@home2 .net;gr=urn:uuid: f 81d4fae-7dec-lldO-a762-OOaOc91e6bf 6>/> 
< /controlTransf er>> 
Require: target -dialog 

Target -dialog: Cb03a0s09a2sdf glkj 13579 ; to- tag=abcdef ; f rom-tag=123456 
Ref erred-By : sip : user l_publicl@homel . net 

Contact : sip: user l_publicl@homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz ; +g . 3gpp . 

current - iut -control ler=passive 
Accept : message/sipf rag, application/vnd . 3gpp . iut+xml 
Content -Length: 



3-4. SIP 202 (Accepted) response 

The SCC AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)- 

The SCC AS sends a SIP NOTIFY request to UE-1 to notify impUcit subscription to the SIP REFER request 
results. 

7-8. SIP 200 (OK) response (UE-1 to SCC AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC AS. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.10.2- 
9 

The SCC AS sends a SIP re-INVITE request towards the Controllee UE (UE-2). The re-INVITE request 
contains the XML body from the URI in the Refer-To header field from the SIP REFER request. 
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Table A.1 0.2-9: SIP re-INVITE request (SCO AS to IM CN subsystem entities) 



INVITE sip:user2 j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 
Route : 

To : sip : user2_publicl@homel . net ; abcdef 
From: sip :user3 j>ublic3@home3 .net ; tag=123456 
Call-ID: 
CSeq: 

Max- Forwards : 
Require : 

Ref erred-By : sip :userl_publicl®homel . net 

Contact : sip :user3_public3@home3 .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Accept : application/vnd . 3gpp . iut+xml 

Content -Type : multipart /mixed ;boundary= "boundaryl " 

Content -Length: {...} 

- -boundaryl 

Content-Type: application/sdp 

v=0 

o=- 1027933615 1027933615 IN 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 

t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

- -boundaryl 

Content -Type : application/vnd. 3gpp . iut+xml ; handling=optional 

<controlTransf er> 

<targetController=<sip :user2_public2@home2 .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a762 - 

00a0c91e6bf 6>/> 
</controlTansf er> 
- -boundaryl 



10. SIP re-INVITE request (intermediate EM CN subsystem entities to UE-2) 

11-12, SIP 200 (OK) response (UE-2 to SCC AS through intermediate EM CN subsystem entities) - see 
example in table A.10.2-11 

UE-2 accepts the transfer of control and indicates this by including a g.3gpp.current-iut-controller media feature 
tag set to Active in the SIP 200 (OK) response it sends to the SCC AS. 
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Table A.1 0.2-11 : SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To : sip : userl_public2@homel . net ; tag=xyzwv 

From: sip : interUEtransf erOexample . net ; tag = 12486 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : sip : user l_public2®homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 ; +g. 3gpp . 

current - iut - control ler=Active 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 

s=- 

c=145.23.77.88 

t = 

m=audio RTP/AVP 97 
m=video 13 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



13-14, SIP ACK request (from SCC AS to UE-2) 

15-16. SIP NOTIFY request (SCC AS to UE-1) - see example table A.10.2-15 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1, to inform about the success status of the 
control transfer. The body of the SIP NOTIFY request contains a sipfrag including the Contact header field 
containing the g.3gpp.current-iut-controUer media feature tag set to Active from the received SIP 200 (OK) 
response from UE-2 

Table A.10.2-15: SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2 . 
Via : 

To: sip : userl_publicl®homel . net ; tag = 13579 
From : sip : interUEtransf erOexample . net ; tag=22 55 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : sccasl . homel . example . net 
Allow : 

Event: refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content -Length: (...) 

SIP/2.0 200 OK 

Content- Type =applicat ion/ sdp 

Contact : sip : userl_public2®homel . net ; gr=urn :uuid; f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 ; +g . 3gpp . 
current - iut - control ler=Active 

v=0 
s = - 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



17-18. SIP 200 (OK) response (UE-1 to SCC AS) 
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The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 



This subclause describes signalling flows for media flow transfer. Four different scenarios are considered in the clause: 

- subclause A. 11 .2 shows an example when Media flows transfer initiated by a UE not participating in the ongoing 
collaborative session; 

- subclause A. 11. 3 shows an example when Media flows transfer initiated when no collaborative session has been 
established; 

subclause A. 11 .4 shows an example when Media flows transfer initiated by a controUee UE of an ongoing 
collaborative session; and 

- subclause A.l 1.5 shows an example when ControUee UE initiated addition of media to another controllee UE. 



A.1 1 .2 Media flows transfer initiated by a UE not participating in the 
ongoing collaborative session 



This subclause describes the scenario when the Media flow is transferred from UE-1 to UE-3 requested by UE-3 and the 
UE-3 becomes a new Controllee UE. The flow diagram shows when UE-1 and UE-3 belong to the different 
subscription. The SCC AS-1 is controlling the coUoaborative session. 

UE-1(123.45.67.89) and UE-2 (123.1 12.67.87) are included in a Collaborative Session with the remote UE 
(132.54.76.98), in which UE-1 is the Controller UE and UE-2 is the Controllee UE. Media paths exist between UE-1 
and remote UE( video) and between UE-2 and remote UE(audio). The video component is bidirectional from the remote 
UE to the controller UE, UE-1. The UE-3(123.23.45.67) wants to pull the media flow between UE-1 and remote UE. 
After this procedure, the UE-3 will be in collaborative session. 



AS. 



A.1 1 Signalling flows for nnedia flow transfer 



A.11.1 



Introduction 
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Figure A.11.2-1 : Signalling flow for Media flows transfer initiated by a UE not participating in the 

ongoing collaborative session 

1. UE-3 discovers the sessions of UE-1. 

2-6. SIP REFER request (from UE-3 to controller UE, UE-1) 

The UE-3 sends SIP REFER request to the controller UE, UE-1 to request the media transfer. The SIP REFER 
request is finally routed to the SCC AS-1 serving UE-1. 
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Table A.1 1.2-2: SIP REFER request (UE-3 to UE-1) 



REFER sip :userl_publicl®homel .net ;gr=urn:uuid: f81d4fae-7dec- lldO- 1111 -111111111111 SIP/2.0 

Via: SIP/2. 0/UDP [3333 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7df dsdq 

To: <sip : userl_publicl@homel . net > 

From : <sip : user2_publicl@home2 . net > ; tag=2 94 75 6 

Call-ID: Asdasd23123366 

Cseq: 4897924 REFER 

Max-Forwards: 70 

P- Preferred- Identity : <sip : user2_publicl@home2 . net > ; 

Refer-To : <sip : user2_publicl®home2 .net; gr=urn:uuid: f 81d4f ae- 7dec- lldO - 1111- 3 3 3 3 3 3 3 3 3 3 3 3 ?body= 

m%3Daudio%2 00%2 0RTP%2FAVP%97%0Dm%3Dvideo%2 03 002%2 0RTP%2FAVP%2 098%2 099> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 11111 ; remote- tag=2 73 64 ; local-tag=1192 8 
Ref erred-By : sip : user2_publicl@home2 . net 

Contact : sip :user2_publicl@home2 . net ; gr=urn : uuid : f81d4fae-7dec-lld0- 1111- 333333333333 
Accept -Contact : * ; +g . 3gpp . iut- focus ; explicit ; require 
Accept: application/sdp, message/sipf rag 
Content-Length: 



7-11. SIP 202 (Accepted) response (from SCC AS-1 serving UE-1 to UE-3) 

sec AS-1 serving UE-1 sends a SIP 202 (Accepted) response to UE-3 as response to the SIP REFER request. 

12-16. SIP NOTIFY request (from SCC AS-1 serving UE-1 to UE-3) 

The SCC AS-1 serving UE-1 sends a SIP NOTIFY request to UE-3 to notify implicit subscription to the SIP 
REFER request results. 



Table A.1 1.2-12: SIP NOTIFY request (SCC AS-1 to UE-3) 



NOTIFY sip:user2 publicl@home2 . net ; gr=urn : uuid 


f81d4fae-7dec-lld0- 1111- 333333333333 SIP/2 . 


Via: 




To : sip : user2 public2@home2 . net ; tag=1234 




From: sip : sip : interUEtransf erOsccasl . homel . net 


tag=3456 


Call-ID: 




CSeq: 




P- Asserted- Identity : 




Require : 




Contact : sip : interUEtransf er@sccasl . homel . net 




Allow : 




Event : refer 




Subscription-State : active; expires=3600 




Content-Type: message/sipf rag; version=2.0 




Content-Length: (...) 




SIP/2.0 100 Trying 





17-21. SIP 200 (OK) response (from UE-3 to SCC AS-1 serving UE-1) 

The UE-3 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS-1. 

22-26. SIP INVITE request (from SCC AS-1 serving UE-1 to UE-3) 

Since the message 2-6 contains a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
video line which is not currently supported by another UE than controller UE, the SCC AS-1 realizes the 
procedure is for transferring the media from that controller UE (UE-1) to UE-3. The SCC AS-1 sends a SIP 
INVITE request to the UE-3, to transfer the video media component. 
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Table A.11.2-22: SIP INVITE request (SCO AS-1 serving UE-1 to UE-3) 



INVITE sip:user2_publicl@home2 .net; gr=urn : uuid : f81d4fae- 7dec- lldO- 1111-333333333333 SIP/2.0 
Via: SIP/2. 0/UDP sccasl.homel.net; branch=z9hG4bK332b33 . 3 ; 
To : sip : user2_publicl®home2 . net ; 

From: sip : interUEtransf erOsccasl . homel . net ; tag=12486 

Call-ID: Cb03a0s09a2sdfglkj33333 

Cseq: 111 INVITE 

Max-Forwards: 70 

P- Asserted- Identity : 

Require : 

Contact : sip : interUEtransf erOsccasl . homel . net ; +g. 3gpp . iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



27-31. SIP 200 (OK) response (from UE-3 to SCC AS-1 serving UE-1) 

The target UE, UE-3, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCCAS-1. 

Table A.1 1.2-27: SIP 200 (OK) response (UE-3 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 
Via : 

To: sip : user2_publicl@home2 . net ; tag = 24861 

From: sip : interUEtransf er@sccasl . homel .net ; tag = 12486 

Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : <sip:user2_publicl@home2 .net ; gr=urn :uuid: f81d4fae- 7dec- lldO- 1111 -333333333333 > 

Allow: 

Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.67 
s=- 

c=123.23.45.67 

t = 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
a=recvonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



32-36. SIP ACK request (from SCC AS-1 serving UE-1 to target UE; UE-3) 

The SCC AS-1 serving UE-1 sends a SIP ACK request to the UE-3. 
37-38. SIP re-INVITE request (from SCC AS-1 serving UE-1 to controller UE; UE-1) 
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Table A.11.2-37: SIP INVITE request (SCO AS-1 serving UE-1 to UE-1) 



INVITE sip : user l_publicl@homel .net ; gr=urn :uuid: f S 


Jld4fae-7dec-lld0- 1111 -111111111111 SIP/2 .0 


Via : 




To: sipiuserl publiclohomel . net ; Tag=11928 




FroTn : sipiuseicR put)licl@hoTneR. net ; tac(=27364 




Call-ID: Cb03a0s09a2sdfglkjlllll 




CSeq: 




Max- Forwards : 




P- Asserted- Identity : 




Require : 




Contact : sip : interUEtransf erOsccasl . homel . net ; +g 


3gpp. iut- focus 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 132.54.76.98 




s = - 

C=IN IP4 132.54.76.98 




t = 




m=audio RTP/AVP 97 




m=video 3002 RTP/AVP 98 99 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




a=sendonly 





39-40, SIP 200 (OK) response (from controller UE, UE-1 to SCC AS-1 serving UE-1) 

The UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.11.2-39: SIP 200 (OK) response (UE-1 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip :userl_publicl®homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO - 1111- 111111111111> ; 

+g . 3gpp . iut-controller 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 

c=123.45.67.89 
t = 

m=audio RTP/AVP 97 
m=video 13 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a= inactive 



41-42. SIP ACK request (from SCC AS-1 serving UE-1 to controUer UE; UE-1) 

The SCC AS-1 serving UE-1 sends a SIP ACK request to the UE-1. 
43-45. SIP re-EWITE request (from SCC AS-1 serving UE-1 to remote UE) 

The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to the remote UE. 
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Table A.11.2-43: SIP INVITE request (SCO AS-1 serving UE-1 to remote UE) 



INVITE sip:userR_j)ublicl@homeR.net SIP/2.0 
Via : 

To : sip : userR_publicl®homeR . net ; tag=2 73 64 
From : sip : user l_publicl®homel . net ; tag=11928 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : <sip : interUEtransf erOsccasl . homel . net> 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123.112.67.87 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
c=IN IP4 123.23.45.67 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



46-48. SIP 200 (OK) response (from remote UE to SCC AS-1 serving UE-1) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC AS-1. 

Table A.11.2-46: SIP 200 (OK) response (remote UE to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : userR_publicl@homeR . net 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



49-51. SIP ACK request (from SCC AS-1 serving UE-1 to remote UE) 
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The sec AS-1 serving UE-1 sends a SIP ACK request to the remote UE. 
52-56. SIP re-EWITE request (from SCC AS-1 serving UE-1 to UE-3) 

The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to UE-3 to activate the video media component. 

Table A.1 1.2-52: SIP INVITE request (SCC AS-1 serving UE-1 to UE-3) 



INVITE sip:user2_publicl@home2 .net; gr=urn :uuid : f81d4fae- 7dec- lldO- 1111-333333333333 SIP/2.0 
Via: SIP/2. 0/UDP sccasl.homel.net; branch=z9hG4bK332b33 . 3 ; 

To : sip : user2_publicl®home2 . net ; 

From: sip : interUEtransf erOsccasl . homel .net ; tag=12486 

Call-ID: Cb03a0s09a2sdfglkj33333 

Cseq: 111 INVITE 

Max-Forwards: 70 

P- Asserted- Identity: 

Require : 

Contact : sip: interUEtransf er@sccasl .homel .net ; +g. 3gpp. iut- focus 

Allow : 
Accept : 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132 . 54 . 76 . 98 

t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



57-61. SIP 200 (OK) response (from UE-3 to SCC AS-1 serving UE-1) 

The target UE, UE-3, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCCAS-1 serving UE-1. 

Table A.11.2-57: SIP 200 (OK) response (UE-3 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 
Via: 

To: sip : user2_publicl@home2 . net ; tag = 24861 

From: sip : interUEtransf erasccasl . homel . net ; tag = 12486 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip :user2publicl@home2 .net ;gr=urn:uuid: f81d4fae- 7dec-lld0- 1111 -333333333333 > 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.67 
s=- 

c=123.23.45.67 
t = 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



62-66. SIP ACK request (from SCC AS-1 serving UE-1 to target UE; UE-3) 

The SCC AS-1 serving UE-1 sends a SIP ACK request to the UE-3. 
67-68. SIP re-INVITE request (from SCC AS-1 serving UE-1 to controller UE; UE-1) 
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The sec AS-1 sends a SIP re-INVITE request to the controller UE. Since UE-1 keep the collaborative session 
control, sec AS-1 sends the re-INVITE instead of BYE in spite of no media flow at UE-1. 

Table A.11.2-67: SIP INVITE request (SCC AS-1 serving UE-1 to UE-1) 



INVITE sip : userl_publicl@homel. net ;gr=urn:uuid:f81d4fae-7dec-lld0- 1111 -111111111111 SIP/2 .0 
Via: 

To : sip :userl_publicl@homel . net ; Tag=1192 8 
From: sip :userR_publicl@homeR.net ; tag=27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : interUEtransf erOsccasl . homel . net 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132 .54.76.98 

t = 

m=audio RTP/AVP 97 
m=video RTP/AVP 98 99 



69-70. SIP 200 (OK) response (from controller UE, UE-1 to SCC AS-1 serving UE-1) 

The UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.11.2-69: SIP 200 (OK) response (UE-1 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip :userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-llll-llllllllllll> ; 

+g. 3gpp . iut-controller 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s=- 

c=123.45.67.89 

t = 

m=audio RTP/AVP 97 
m=video RTP/AVP 98 99 



71-72. SIP ACK request (from SCC AS-1 serving UE-1 to controUer UE; UE-1) 

The SCC AS-1 sends a SIP ACK request to the UE-1. 

73-77. SIP NOTIFY request (from SCC AS-1 serving UE-1 to UE-3) 

The SCC AS-1 serving UE-1 sends a SIP NOTIFY request including the SIP final response as a sipfrag body to 
the UE-3 to inform about the success status of the inter-UE transfer. 
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Table A.1 1.2-73: SIP NOTIFY request (SCC AS-1 to UE-3) 



NOTIFY sip :user2 public l@home2 . net ; gr=urn : uuid : f81d4fae- 7dec- lldO - 1111-333333333333 SIP/2.0 
Via : 

To : sip : user2_public2@home2 . net ; tag=1234 

From : sip : sip : interUEtransf erOsccasl . homel . net ; tag=34 56 

Call-ID: 

CSeq: 

P- Asserted- Identity : 
Require : 

Contact : sip : interUEtransf erSsccasl . homel . net 

Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag; version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

Contact : <sip : userl_publicl®homel . net ;gr=urn : uuid : f 8 ld4fae- 7dec- lldO - 1111- 111111111111 > ; 

+g . 3gpp . iut- controller 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 

c=123 .45.67.89 
t = 

m=audio RTP/AVP 97 
m=video RTP/AVP 98 99 



78-82. SIP 200 (OK) response (from UE-3 to SCC AS-1 serving UE-1) 

The UE-3 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS-1. 

A.1 1 .3 Media flows transfer initiated when no collaborative 
session has been established 

This subclause describes the scenario when the media flow is transferred from UE-1 to UE-2 requested by UE-2. The 
flow diagram shows when UE-1 and UE-2 belong to the same subscription. 

Media path exist between UE-1(123.45.67.89) and Remote UE(132.54.76.98). UE-2(123.1 12.67.87) wants to pull the 
video media flow between UE-1 and Remote-UE. After this procedure, collaborative session will be established. 
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Figure A.11.3-1 Signaiiing flow for Media flow transfer initiated when no collaborative session has 

been established 



1-2. UE-1 is in session with Remote UE 

There is a multimedia session comprising audio and video media between the UE-1 and the Remote UE 
anchored at SCC AS. 

3. UE-2 discovers the session of UE-1 

4-5. SIP REFER request (from UE-2 to SCC AS) 

The UE-2 sends SIP REFER request to the UE-1 to request the media transfer from UE-1 to UE-2. The SIP 
REFER request is routed to the SCC AS by filter criteria. The SCC AS does not route the SIP REFER request to 
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the address set in the Request-URI if there is the g.3gpp.iut-focus media feature tag in the Accept-Contact header 
field. 

Table A.1 1.3-4: SIP REFER request (UE-2 to SCC AS) 



REFER sip:userl_publicl®homel.net; gr=urn : uuid : f81d4fae - 7dec - lldO - 1111 - 111111111111 SIP/2.0 

Via: SIP/2. 0/UDP [3333 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7df dsdq 

To: <sip: userl_publicl@homel . net> 

From : <sip : userl_public2@homel . net > ; tag=2 94 756 

Call-ID: Asdasd23123366 

Cseq: 4897924 REFER 

Max-Forwards: 70 

P- Preferred- Identity : <sip : userl_public2@homel . net > ; 

Refer-To: <sip :userl_public2@homel .net; gr=urn:uuid: f 8 ld4fae-7dec -lldO- 1111 -222222222222 ?body= 

m%3Daudio%2 00%2 0RTP%2FAVP%97%0Dm%3Dvideo%2 03 002%2 0RTP%2FAVP%2 09B%2 099> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 11111 ; remote- tag=2 73 64 ; local-tag=1192 8 
Ref erred-By : sip : userl_public2@homel . net 

Contact : sip :userl_public2@homel . net ; gr=urn : uuid : f 8 ld4fae - 7dec - lldO - 1111-222222222222 
Accept-Contact : +g . 3gpp . iut- focus ; explicit ; require 
Accept: application/sdp, message/sipf rag 
Content-Length: 

~6^. SIP 202 (Accepted) response (from SCC AS to UE-2) 

SCC AS sends a SIP 202 (Accepted) response to UE-2 as response to the SIP REFER request. 

8-9. SIP NOTIFY request (from SCC AS to UE-2) 

The SCC AS sends a SIP NOTIFY request to UE-2 to notify implicit subscription to the SIP REFER request 
results. 



Table A.1 1.3-8: SIP NOTIFY request (SCC AS to UE-2) 



NOTIFY sip:userl public2®homel . net ; gr=urn : uuid 


f 81d4f ae-7dec-lldO-llll-222222222222 SIP/2 . 


Via : 




To : sip : userl public2@homel . net ; tag=1234 




From : sip : sip : interUEtransf erOsccasl . homel . net 


tag=3456 


Call-ID: 




CSeq: 




P- Asserted- Identity : 




Require : 




Contact : sip : interUEtransf erOsccasl . homel . net 




Allow: 




Event : refer 




Subscription-State : active; expires=3G00 




Content-Type: message/sipf rag; version=2.0 




Content-Length: (...) 




SIP/2.0 100 Trying 





10-11. SIP 200 (OK) response (from UE-2 to SCC AS) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 

12-13. SIP INVITE request (from SCC AS to UE-2) 

Since the 4-5 SIP REFER request contains a Refer-to header field addressed to UE-2 and the URI parameters, 
Usting a video line which is transferred and an audio line with port number set to zero which is not transferred, 
The SCC-AS sends a SIP INVITE request to the UE-2, to transfer the video media component. In order to avoid 
to UE-2 to start sending video to the Remote UE, the SCC AS add an a line to sendonly in the SDP offer. 
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Table A.11.3-12: SIP INVITE request (SCC-AS to UE-2) 



INVITE sip: userl_public2@homel.net; gr=urn : uuid : f 81d4f ae- 7dec-lld0-llll-222222222222 SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
To : sip : userl_public2®homel . net ; 

From: sip : interUEtransf erOsccasl . homel . net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

Cseq: 111 INVITE 

Max-Forwards: 70 

P- Asserted- Identity : 

Require : 

Contact : sip : interUEtransf erOsccasl . homel . net ; +g. 3gpp . iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



14-15, SIP 200 (OK) response (from UE-2 to SCC-AS) 

The target UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the SCC 
AS. 

Table A.11.3-14: SIP 200 (OK) response (UE-2 to SCC AS) 



SIP/2.0 200 OK 
Via : 

To: sip : userl_public2@homel . net ; tag=36527 

From: sip : interUEtransf erOsccasl . homel .net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

CSeq: 

P -Preferred- Identity : 

Contact : <sip:userl j)ublic2@homel .net ;gr=urn:uuid: f81d4fae- 7dec-lld0- 1111 -222222222222 > 

Allow: 

Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

c=123.112.67.87 

t = 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
a=inactive 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



16-17. SIP ACK request (from SCC AS to UE-2) 

The SCC AS sends a SIP ACK request to the UE-2. 
18-19. SIP re-INVITE request (from SCC AS to UE-1) 

The SCC-AS sends a SIP re-INVITE request to the UE-1 to hold the video media session to be transferred. 
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Table A.11.3-18: SIP INVITE request (SCO AS to UE-1) 



INVITE sip : user l_publicl@homel .net ; gr=urn :uuid: f S 


Jld4fae-7dec-lld0- 1111 -111111111111 SIP/2 .0 


Via : 




To: sipiuserl publiclohomel . net ; Tag=11928 




FroTn : sipiuseicR publicl@hoTne2.net; tac(=27364 




Call-ID: Cb03a0s09a2sdfglkjlllll 




CSeq: 




Max- Forwards : 




P- Asserted- Identity : 




Require : 




Contact : sip : interUEtransf erOsccasl . homel . net ; +g 


3gpp. iut- focus 


Allow: 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 132.54.76.98 




s = - 

C=IN IP4 132.54.76.98 




t = 




m=video 3002 RTP/AVP 98 99 




a=sendonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




m=audio 3000 RTP/AVP 97 




b=AS : 25 . 4 




a=rtpmap : 96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 




a=rtpmap:97 telephone -event 




a=maxpt ime : 2 





20-21. SIP 200 (OK) response (from UE-1 to SCC AS) 

The UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.11.3-20: SIP 200 (OK) response (UE-1 to SCC AS) 



SIP/2.0 200 OK 

Via : 

To: 

From : 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip : userlpubliclOhomel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-llll-llllllllllll> ; 

+g . 3gpp . iut -controller 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 

c=123 .45.67.89 
t = 

m=audio 1300 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 20 

m=video 1202 RTP/AVP 98 99 

a=inactive 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



22-23. SIP ACK request (from SCC AS to UE-1) 
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The sec AS sends a SIP ACK request to the UE-1. 

24-26. SIP re-EVVITE request (from SCC AS to remote UE) 

The SCC AS sends a SIP re-INVITE request to the remote UE. 

Table A.1 1.3-24: SIP INVITE request (SCC AS to remote UE) 



INVITE sip:userR_publicl@home2 .net SIP/2.0 
Via : 

To : sip : userR_publicl®home2 . net ; tag=27364 
From : sip : userl_publicl®homel . net ; tag=1192 8 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : <sip; interUEtransf er@sccasl .homel .net> 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
c=IN IP4 123.112.67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



27-29. SIP 200 (OK) response (from Remote UE to SCC AS) 

The Remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC AS. 
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Table A.11.3-27: SIP 200 (OK) response (Remote UE to SCO AS) 



SIP/2.0 200 OK 






Via : 






To : 






From : 






Call-ID: 






CSeq : 






P- Asserted- Identity : 






Contact: sipiuserR publicl®home2 


net 




Allow: 






Content-Type: application/sdp 






Content -Length: (...) 






v=0 






o=- 1027933615 1027933615 IN IP4 


132 .54 


76.98 


s=- 

C=IN IP4 132.54.76.98 






t = 






m=audio 3000 RTP/AVP 97 






b=AS : 2 5 . 4 






a=rtpmap:96 AMR 






a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode 


-change 


-period=2 


a=rtpmap:97 telephone-event 






a=maxptime : 20 






m=video 3002 RTP/AVP 98 99 






b=AS : 75 






a=rtpmap:98 H263 






a=fmtp:98 prof ile-level-id=0 






a=rtpmap:99 MP4V-ES 







30-32. SIP ACK request (from SCC AS to Remote UE) 

The SCC-AS sends a SIP ACK request to the Remote UE. 
33-34. SIP re-INVITE request (from SCC AS to UE-2) 

The SCC AS sends a SIP re-INVITE request to UE-2 to activate the video media component. 

Table A.11.3-33: SIP INVITE request (SCC AS to UE-2) 



INVITE sip :userl j)ublic2@homel .net ; gr=urn:uuid: f 81d4f ae-7dec-lld0-llll-222222222222 SIP/2.0 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

To: sip:userl j)ublic2@homel .net ; tag=36527 

From: sip : interUEtransf er@sccasl . homel .net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

Cseq: 112 INVITE 

Max- Forwards : 70 

P-Asserted- Identity: 

Require : 

Contact : sip: interUEtransf erOsccasl .homel .net ; +g. 3gpp. iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
b=AS:75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



35-36. SIP 200 (OK) response (from UE-2 to SCC AS) 
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The UE-2 sends a SIP 200 (OK) response to the SCC AS. 

Table A.11.3-35: SIP 200 (OK) response (UE-2 to SCC AS) 



SIP/2.0 200 OK 
Via: 

To: sip:userl j)ublic2@homel .net ; tag=36527 

From: sip : interUEtransf er@sccasl . homel .net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

CSeq: 

P- Preferred- Identity : 

Contact : <sip:userl j)ublic2@homel .net ;gr=urn:uuid: f81d4fae- 7dec-lld0- 1111 -222222222222 > 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s=- 

c=123.112.67.87 
t = 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



37-38. SIP ACK request (from SCC AS to UE-2) 

The SCC AS sends a SIP ACK request to the UE-2. 
40-41. SIP re-EWITE request (from SCC AS to UE-1) 

The SCC-AS sends a SIP re-INVITE request to the UE-1 to release the video media component. 



Table A.1 1.3-40: SIP INVITE request (SCC AS to UE-1) 



INVITE sipiuserl publiciohomel . net ; gr=urn : uuid: f { 


J Id4fae-7dec-lld0- 1111 -111111111111 SIP/2 . 


Via : 




To: sipiuserl publiciohomel . net ; Tag=11928 




From: sipiuserR publicl@home2.net; tag=27364 




Call-ID: Cb03a0s09a2sdfglkj mil 




CSeq: 




Max- Forwards : 




P- Asserted- Identity: 




Require : 




Contact : sip : interUEtransf er@sccasl . homel .net ; +g 


3gpp. iut- focus 


Allow : 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 132.54.76.98 




s=- 

C=IN IP4 132.54.76.98 




t = 




m=audio 3000 RTP/AVP 97 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 




a=rtpmap:97 telephone-event 




a=maxpt ime : 2 




m=video RTP/AVP 98 99 





41-42. SIP 200 (OK) response (from UE-1 to SCC AS) 

The UE-1 sends a SIP 200 (OK) response with an SDP answer. 
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Table A.11 .3-41: SIP 200 (OK) response (UE-1 to SCC AS) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip :userl_publicl®homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO- 1111- 111111111111> ; 
+g . 3gpp . iut-controller 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

c=123.45.67.89 
t = 

m=audio 1300 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video RTP/AVP 98 99 



43-44. SIP ACK request (from SCC AS to UE-1) 

The SCC AS sends a SIP ACK request to the UE-1. 

45-46. SIP NOTIFY request (from SCC AS to UE-2) 

The SCC AS sends a SIP NOTIFY request including the SIP final response as a siplrag body request to the UE- 
2. 
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Table A. 11. 3-45: SIP NOTIFY request (SCC AS to UE-2) 



NOTIFY sip :userl public2(ahomel . net ; gr=urn : uuid : f81d4fae- 7dec- lldO - 1111-222222222222 SIP/2.0 
Via : 

To : sip : user2_publicl@homel . net ; tag=1234 

From : sip : sip : interUEtransf erOsccasl . homel . net ; tag=34 56 

Call-ID: 

CSeq: 

P- Asserted- Identity : 
Require : 

Contact : sip : interUEtransf erSsccasl . homel . net 

Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag; version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

Contact : <sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO - 1111- 

111111111111>; +g. 3gpp. iut- cent roller 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 

c=123 .45.67.89 
t = 

m=audio 1300 RTP/AVP 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video RTP/AVP 98 99 



47-48. SIP 200 (OK) response (from UE-2 to SCC AS) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 



A.1 1 .4 Media flows transfer initiated by a controllee UE of an 
ongoing collaborative session 

This subclause describes the scenario when the Media flow is transferred from Controller UE, UE-1 to Controllee UE, 
UE-2 requested by UE-2. The flow diagram shows when UE-1 and UE-2 belong to the different subscription. 

UE-1 (123.45.67.89) and UE-2 (123.112.67.87) are included in a Collaborative Session with the remote UE 
(132.54.76.98), in which UE-1 is the Controller UE and UE-2 is the Controllee UE. The call is anchored in the SCC 
AS-1 controlling the collaborative session. Prior to transfer the Media flow, UE-2 gets the dialog information such as 
the content type and port numbers on the remote end. This is done by UE-2 having subscribed to dialog event package 
between UE-1 and the SCC AS-1. 
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Figure A.11.4-1 : Signalling flow for IVIedia flows transfer initiated by a controllee UE of an ongoing 

collaborative session 

1. lJE-2 discovers the session of UE-l 

2-6. SIP REFER request (from UE-2 to SCC AS serving UE-l) 

The SIP REFER request contains a Refer-To header field containing a URI of Target UE, UE-2 and a body 
parameter containing an m Hne for audio to be pulled with the port number set to the non-zero port numbers use 
in the SDP parameter from the corresponding media descriptions as received during the last successful SDP 
offer-answer exchange from the Remote UE. The SIP REFER request also includes a Target-dialog header field 
containing the details of the dialog for the existing session between UE-l and Remote-UE. 

Table A.11.4-2 SIP REFER request (UE-2 to SCC AS-1 serving UE-1) 



REFER sip :userl_publicl@homel .net ;gr=urn:uuid: f 8 ld4fae-7dec- lldO- 1111 -111111111111 SIP/2.0 

Via: SIP/2. 0/UDP [2222 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7df dsdq 

To: <sip: userl_publicl@homel.net > 

From : <sip : user2_publicl@home2 . net > ; tag=2 94 75 6 

Call-ID: Asdasd23123366 

Cseq: 4897924 REFER 

Max-Forwards: 70 

P- Preferred- Identity : <sip : user2_publicl@home2 . net > ; 

Refer-To : <sip :user2_publicl®home2 . net ; gr=urn : uuid : f 8 ld4fae - 7dec - lldO - 1111 -222222222222 ? 

body=m%3Daudio%2 03 000%2 0RTP%2FAVP%97%0Dm%3Dvideo%2 03 002%2 0RTP%2FAVP%2 09B%2 099> 
Require: target-dialog 

Target -dialog: cb03a0s0 9a2sdf glkj 11111 ; remote -tag=2 73 64 ; local-tag=1192 8 
Ref erred-By : sip : user2_publicl@home2 . net 

Contact : sip :user2_publicl@home2 . net ; gr=urn : uuid : f 8 ld4fae-7dec- lldO- 1111 -222222222222 
Accept -Contact : * ; +g . 3gpp . iut- focus ; explicit ; require 
Accept: application/sdp, message/sipf rag 
Content-Length: 

7-11. SIP 202 (Accepted) response (from SCC AS-1 serving UE-l to UE-2) 

The SCC AS-1 serving UE-l sends a SIP 202 (Accepted) response to UE-2 as response to the SIP REFER 
request. 

12-16. SIP NOTIFY request (from SCC AS-1 serving UE-l to UE-2) 

The SCC AS-1 serving UE-l sends a SIP NOTIFY request to UE-2 to notify implicit subscription to the SIP 
REFER request results. 

Table A.1 1.4-12: SIP NOTIFY request (SCC AS-1 serving UE-1 to UE-2) 



NOTIFY sip :user2 publicl(ahome2 .net; gr=urn : uuid : f81d4fae- 7dec- lldO - 1111-222222222222 SIP/2.0 
Via : 

To : sip : user2_publicl@home2 . net ; tag=1234 

From : sip : sip : interUEtransf erOsccasl . homel . net ; tag=34 56 

Call-ID: 

CSeq: 

P- Asserted- Identity : 
Require : 

Contact : sip : interUEtransf erSsccasl . homel . net ; +g . 3gpp . iut- focus 

Allow: 

Event : refer 

Subscription-State : active ; expires=3600 
Content-Type: message/sipf rag; version=2.0 
Content-Length: (...) 

SIP/2.0 100 Trying 



17-21. SIP 200 (OK) response (from UE-2 to UE-1) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the UE-1. 

22-26. SIP re-INVITE request (from SCC AS-1 serving UE-1 to UE-2) 

Since the 2-6 SIP REFER request contains a Refer-to header field addressed to UE-2 and the URI paramaters, 
hsting an audio line which is not currently supported by UE-2, the SCC AS-1 realizes the procedure is for 
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transferring the media from that controller UE (UE-1) to UE-2. The SCC-AS-1 sends a SIP re-INVITE request 
to the UE-2, to transfer the audio media component. 

Table A.11.4-22 SIP INVITE request (SCC AS-1 serving UE-1 to UE-2) 



INVITE sip :user2_publicl@home2 . net ; gr=urn : uuid : f 8 ld4fae-7dec -lldO- 1111 -222222222222 SIP/2.0 
Via : SIP/2 . 0/UDP sccasl .homel . example . net ;branch=z9hG4bK332b33 . 3 ; 
To : sip : user2_publicl@home2 . net ; 

From : sip : interUEtransf er@example . net ; tag=2 7365 

Call-ID: Cb03a0s09a2sdfglkj22222 

Cseq: 111 INVITE 

Max-Forwards: 70 

P- Asserted- Identity : 

Require : 

Contact: sip : interUEtransf erOexample . net ; +g . 3gpp . iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 97 
a=sendonly 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone -event 
a=maxptime : 2 

m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



27-31. SIP 200 (OK) response (from UE-2 to SCC-AS-1 serving UE-1) 

The target UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the SCC 
AS serving UE- 1 . 
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Table A.11.4-27 SIP 200 (OK) response (UE-2 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 
Via : 

To: sip : user2_publicl®home2 . net ; tag=36527 
From: sip : interUEtransf erOexample . net ; tag=27365 
Call-ID: Cb03a0s09a2sdfglkj22222 
CSeq: 

P- Preferred- Identity : 

Contact : <sip:user2_publicl@home2 . net ; gr=urn :uuid : f81d4fae- 7dec- lldO- 1111-222222222222 > 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.87 
s = - 

c=123.23.45.87 
t = 

m=audio 1300 RTP/AVP 97 
a=inactive 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 20 

m=video 1302 RTP/AVP 98 99 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



32-36. SIP ACK request (from SCC AS-1 serving UE-1 to UE-2) 

The SCC AS-1 serving UE-1 sends a SIP ACK request to the UE-2. 

37-38. SIP re-INVITE request (from SCC AS-1 serving UE-1 to UE-1) 

The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to the UE-1 to hold the video media session to be 
transferred. 

Table A.1 1.4-37 SIP INVITE request (SCC AS-1 serving UE-1 to UE-1) 



INVITE sip : userl_publicl@homel. net ;gr=urn:uuid:f81d4fae-7dec-lld0- 1111 -111111111111 SIP/2 .0 
Via: 

To: sip:userl j)ublicl@homel .net ;Tag=1192 8 
From: sip :userR_publicl®homeR . net ; tag=27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip: interUEtransf erSexample .net ; +g. 3gpp. iut- focus 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s=- 

C=IN IP4 132.54.76.98 

t = 

m=audio 3 000 RTP/AVP 97 
a=sendonly 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video RTP/AVP 98 99 



39-40. SIP 200 (OK) response (from UE-1 to SCC AS serving UE-1) 
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The UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.11.4-39 SIP 200 (OK) response (UE-1 to SCO AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip :userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-llll-llllllllllll> ; 

+g. 3gpp. iut-controller 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s=- 

c=123.45.67.89 
t = 

m=audio 1200 RTP/AVP 97 
a= inactive 
b=AS:25.4 
a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video RTP/AVP 98 99 



41-42. SIP ACK request (from SCC AS-1 serving UE-1 to UE-1) 

The SCC AS serving UE-1 sends a SIP ACK request to the UE-1. 
43-45. SIP re-INVITE request (from SCC AS-1 serving UE-1 to remote UE) 

The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to the remote UE. 

Table A.11.4-45 SIP INVITE request (SCC AS-1 serving UE-1 to remote UE) 



INVITE sip : userR_publicl@homeR . net SIP/2.0 
Via : 

To : sip : userR_publicl@homeR . net ; tag=27364 
From : sip : userl_publicl@homel . net ; tag=1192 8 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : <sip : interUEtransf er@example .net> 

Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123.112.67.87 

b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
c=IN IP4 123.112.67.87 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 
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46-48. SIP 200 (OK) response (from Remote UE to SCC AS-1 serving UE-1) 

The Remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC AS-1 
serving UE-1. 

Table A.11.4-46 SIP 200 (OK) response (Remote UE to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via : 

To: 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : userR_publicl@homeR . net 
Allow : 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 

t = 

m=audio 3000 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 iyiP4V-ES 



49-51. SIP ACK request (from SCC AS serving UE-1 to Remote UE) 

The SCC- AS serving UE-1 sends a SIP ACK request to the Remote UE. 
52-56. SIP re-INVITE request (from SCC AS serving UE-1 to UE-2) 

The SCC AS serving UE-1 sends a SIP re-INVITE request to UE-2 to activate the video media component. 
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Table A.11.4-52 SIP INVITE request (SCO AS-1 serving UE-1 to UE-2) 



INVITE sip:user2_publicl@home2 .net; gr=urn : uuid : f81d4fae - 7dec- lldO - 1111-222222222222 SIP/2.0 

Via: SIP/2. 0/UDP sccasl.homel.example.net; branch=z9hG4bK332b33 . 3 ; 

To: sip : user2_publicl®home2 . net ; tag=36527 

From: sip : interUEtransf erOexample . net ; tag=27365 

Call-ID: Cb03a0s09a2sdfglkj22222 

Cseq: 112 INVITE 

Max-Forwards: 70 

P- Asserted- Identity : 

Require : 

Contact : sip : interUEtransf erOexample . net ; +g. 3gpp . iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 

s=- 

c=IN IP4 132.54.76.98 

t = 

m=audio 3000 RTP/AVP 97 
b=AS : 25 . 4 
a=rtpmap : 96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 

a=maxptime : 20 

m=video 3002 RTP/AVP 98 99 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



57-61. SIP 200 (OK) response (from UE-2 to SCC AS-1 serving UE-1) 

The UE-2 sends a SIP 200 (OK) response to the SCC AS serving UE-1. 

Table A.1 1.4-57 SIP 200 (OK) response (UE-2 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 
Via : 

To: sip : user2_publicl@home2 . net ; tag=36527 
From: sip : interUEtransf erOexample . net ; tag=27365 
Call-ID: Cb03a0s09a2sdfglkj22222 
CSeq: 

P -Preferred- Identity : 

Contact : <sip:user2 j)ublicl@home2 .net ;gr=urn:uuid: f81d4fae- 7dec-lld0- 1111 -222222222222 > 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.87 
s=- 

c=123.23.45.87 

t = 

m=audio 1300 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=video 1302 RTP/AVP 98 99 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



62-66. SIP ACK request (from SCC AS-1 serving UE-1 to UE-2) 

The SCC AS serving UE-1 sends a SIP ACK request to the UE-2. 
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67-68. SIP re-EWITE request (from SCC AS-1 serving UE-1 to UE-1) 

The SCC-AS serving UE-1 sends a SIP re-INVITE request to the UE-1 to release the video media component. 

Table A.11.4-67 SIP INVITE request (SCC AS-1 serving UE-1 to UE-1) 



INVITE sip : userl_publicl@homel. net ;gr=urn:uuid:f81d4fae-7dec-lld0- 1111 -111111111111 SIP/2 .0 
Via: 

To : sip :userl_publicl®homel . net ; Tag=1192 8 
From: sip :userR_publicl@homeR . net ; tag=27364 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip: interUEtransf er@example .net 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video RTP/AVP 98 99 



69-70. SIP 200 (OK) response (from UE-1 to SCC AS-1 serving UE-1) 

The UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.11.4-69 SIP 200 (OK) response (UE-1 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : <sip :userl_publicl@homel .net ; gr=urn:uuid: f 81d4f ae-7dec-lld0-llll-llllllllllll> ; 

+g. 3gpp . iut-controller 
Allow: 

Content-Type: application/sdp 
Content -Length : (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s=- 

c=123.45.67.89 

t = 

m=audio RTP/AVP 97 
m=video RTP/AVP 98 99 



71-72. SIP ACK request (from SCC AS-1 serving UE-1 to UE-1) 

The SCC AS serving UE-1 sends a SIP ACK request to the UE-1. 

73-77. SIP NOTIFY request (from SCC AS-1 serving UE-1 to UE-2) 

The SCC AS serving UE-1 sends a SIP NOTIFY request including the SIP final response as a sipfrag body to the 
UE-2 to inform about success status of transferring the media from UE-1 to the UE-2. 
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Table A.11.4-73: SIP NOTIFY request (SCC AS-1 serving UE-1 to UE-2) 



NOTIFY sip :user2 public l@home2 .net; gr=urn : uuid : f81d4fae- 7dec- lldO - 1111-222222222222 SIP/2.0 
Via : 

To : sip : user2_publicl@home2 . net ; tag=1234 

From : sip : sip : interUEtransf erOsccasl . homel . net ; tag=34 56 

Call-ID: 

CSeq: 

P- Asserted- Identity : 
Require : 

Contact : sip : interUEtransf erSsccasl . homel . net ; +g . 3gpp . iut- focus 

Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag; version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

Contact : <sip : userl_publicl®homel . net ;gr=urn : uuid : f 8 ld4fae- 7dec- lldO - 1111- 111111111111 > ; 

+g . 3gpp . iut -cent roller 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 

c=123 .45.67.89 
t = 

m=audio RTP/AVP 97 
m=video RTP/AVP 98 99 



78-82. SIP 200 (OK) response (from UE-2 to SCC AS-1 serving UE-1) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS-1 serving 
UE-1. 



A.1 1 .5 Controllee UE initiated addition of media to another 
controllee UE 

This subclause describes the scenario when controllee UE, UE-2 initiate addition of a media to another controllee UE, 
UE-3. The flow diagram shows when UE-1 and UE-2, UE-3 belong to the different subscription. 

Note: When UE-1 and UE-2, UE-3 belong to the same subscription. Serving SCC AS of UE-1, UE-2 and UE-3 are 
same. 

UE-1(123.45.67.89), UE-2 (123.112.67.87) and UE-3(123.23.45.67) are included in a Collaborative Session with the 
remote UE (132.54.76.98), in which UE-1 is the controller UE and UE-2 and UE-3 are the controllee UEs. The 
Collaborative Session is controlled by SCC AS-1. Media paths exist between UE-2 and remote UE (audio) and between 
UE-3 and remote UE (video). The UE-2(123.23.45.67) wants to add another media flow between UE-3 and remote UE 
(video). 
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Figure A.11.5-1 : Signalling flow for controllee UE initiated addition of media to another controllee UE 

1. lJE-2 discovers the information of the collaborative session. 
2-6. SIP REFER request (from UE-2 to UE-1) 
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The UE-2 sends SIP REFER request to the controller UE, UE-1 to request addition of media to UE-3. The SIP 
REFER request is finally routed to the SCC AS-1 serving UE-1. 

Table A.1 1.5-2: SIP REFER request (UE-2 to UE-1) 

REFER sip :userl_publicl@homel .net ;gr=urn:uuid: f81d4fae-7dec- lldO- 1111- 111111111111 SIP/2 . 

Via: SIP/2. 0/UDP [3333 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7df dsdq 

To : <sip : userl_publicl@homel . net> 

From : <sip : user2_publicl@home2 . net > ; tag=2 94 756 

Call-ID: Asdasd23123366 

Cseq: 4897924 REFER 

Max-Forwards: 70 

P- Preferred- Identity : <sip : user2_publicl®home2 . net > ; 

Refer-To: <sip : userl_public3®homel . net ; gr=urn : uuid : f 8 ld4fae-7dec -lldO- 1111 -333333333333 ?body= 
m%3Daudio%2 0%2 0RTP%2FAVP%9 7%0Dm%3Dvideo%2 03 002%2 0RTP%2FAVP%2 098%2 099%3E 
m%3Dvideo%2 09%2 0RTP%2FAVP%2 098%2 099> 

Ref erred-By : sip : user2_publicl@home2 . net 

Target -dialog: cb0 3a0s0 9a2sdf glkj 11111 ; remote- tag=2 73 64 ; local-tag=1192 8 

Contact: sip :user2 publicl@home2 . net ; gr=urn : uuid : f 8 ld4fae-7dec -lldO- 1111 -222222222222 

Ref erred-By : sip : user2_publicl®home2 . net 

Accept: application/sdp, message/sipf rag 

Content-Length: 



7-11. SIP 202 (Accepted) response (from SCC AS-1 serving UE-1 to UE-2) 

SCC AS-1 serving UE-1 sends a SIP 202 (Accepted) response to UE-2 as response to the SIP REFER request. 

12-16. SIP NOTIFY request (from SCC AS-1 serving UE-1 to UE-2) 

The SCC AS-1 serving UE-1 sends a SIP NOTIFY request to UE-2 to notify implicit subscription to the SIP 
REFER request results. 



Table A.1 1.5-12: SIP NOTIFY request (SCC AS-1 serving UE-1 to UE-2) 



NOTIFY sip:user2 publicl@home2 . net ; gr=urn : uuid 


f 8 ld4fae-7dec -lldO- 1111 -222222222222 SIP/2.0 


Via: 




To : sip : user2 publicl@home2 . net ; tag=1234 




From: sip : sip : interUEtransf erOsccasl . homel . net 


tag=3456 


Call-ID: 




CSeq: 




P- Asserted- Identity : 




Require : 




Contact : sip : interUEtransf erOsccasl . homel . net 




Allow : 




Event : refer 




Subscription-State : active; expires=3600 




Content-Type: message/sipf rag; version=2.0 




Content-Length: (...) 




SIP/2.0 100 Trying 





17-21. SIP 200 (OK) response (from UE-2 to SCC AS-1 serving UE-1) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS-1 serving 
UE-1. 

22-26. SIP re-INVITE request (from SCC AS-1 serving UE-1 to UE-3) 

Since the message 2-6 contains a Refer-to header field addressed to UE-3 and the URI parameters, listing an 
audio line which is not currently supported by UE-3, the SCC AS realizes the procedure is for adding the media 
to UE-3. The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to the UE-3, to add the video media 
component. 
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Table A.11.5-22: SIP INVITE request (SCO AS-1 serving UE-1 to UE-3) 



INVITE sip:user3_publicl@home2 .net; gr=urn : uuid : f81d4fae- 7dec- lldO- 1111-333333333333 SIP/2.0 

Via: SIP/2. 0/UDP sccasl.homel.net; branch=z9hG4bK332b33 . 3 ; 

To : sip : user3_publicl®home2 . net ; 

From: sip : interUEtransf erohome . net ; tag=12486 

Call-ID: Cb03a0s09a2sdfglkj33333 

Cseq: 115 INVITE 

Max-Forwards: 70 

P- Asserted- Identity : 

Require : 

Contact : sip : interUEtransf erOsccasl . homel . net ; +g. 3gpp . iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
m=video 9 RTP/AVP 98 99 

a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 iyiP4V-ES 



27-31. SIP 200 (OK) response (from UE-3 to SCC AS-1 serving UE-1) 

The target UE, UE-3, acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC 
AS-1 serving UE-1. 

Table A.1 1.5-27: SIP 200 (OK) response (UE-3 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 
Via : 

To: sip :user3_publicl®home2 .net ; tag = 24861 
From: sip : interUEtransf er@home .net ; tag = 12486 

Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : <sip:user3_publicl@home2 .net ; gr=urn :uuid: f81d4fae- 7dec-lld0- 1111 -333333333333 > 

Allow : 

Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.67 

s=- 

c=123.23.45.67 

t = 

m=audio RTP/AVP 97 
m=video 13 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=video 1304 RTP/AVP 98 99 

a=recvonly 

b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



32-36. SIP ACK request (from SCC AS-1 serving UE-1 to UE-3) 
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The sec AS-1 serving UE-1 sends a SIP ACK request to the UE-3. 
37-39. SIP re-EWITE request (from SCC AS-1 serving UE-1 to remote UE) 

The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to the remote UE. 

Table A.1 1.5-37 SIP INVITE request (SCC AS-1 serving UE-1 to remote UE) 



INVITE sip:user4_publicl@home2 .net SIP/2.0 
via : 

To : sip : user4_publicl®home2 . net ; tag=27364 
From : sip : userl_publicl®homel . net ; tag=1192 8 
Call-ID: Cb03a0s09a2sdfglkjlllll 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : <sip; interUEtransf er@sccasl .homel .net> 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 

t = 

m=audio 1300 RTP/AVP 96 97 
C=IN IP4 123.112.67.87 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video 13 02 RTP/AVP 98 99 
c=IN IP4 123.23.45.67 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 9 9 MP4V- ES 

m=video 13 04 RTP/AVP 98 99 

C=IN IP4 123.23.45.67 

b=AS : 75 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



40-42. SIP 200 (OK) response (from remote UE to SCC AS-1 serving UE-1) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC AS -1 
serving UE-1. 
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Table A.11.5-40: SIP 200 (OK) response (remote UE to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 

Via : 

To : 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user4_publicl®home2 . net 
Allow: 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio 3000 RTP/AVP 97 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
m=video 3004 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



43-45. SIP ACK request (from SCC AS-1 serving UE-1 to remote UE) 

The SCC AS-1 serving UE-1 sends a SIP ACK request to the remote UE. 
46-50. SIP re-EWITE request (from SCC AS-1 serving UE-1 to UE-3) 

The SCC AS-1 serving UE-1 sends a SIP re-INVITE request to the controllee UE. 
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Table A.11.5-46: SIP INVITE request (SCO AS-1 serving UE-1 to UE-3) 



INVITE sip:user3_publicl@home2 .net; gr=urn : uuid : f81d4fae- 7dec-lld0- 1111-333333333333 SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK3 32b33 . 3 ; 
To : sip : user3_publicl®home2 . net ; 

From: sip : interUEtransf erOsccasl . homel . net ; tag=12486 

Call-ID: Cb03a0s09a2sdfglkj33333 

Cseq: 111 INVITE 

Max-Forwards: 70 

P- Asserted- Identity : 

Require : 

Contact : sip : interUEtransf erOsccasl . homel . net ; +g. 3gpp . iut- focus 

Allow: 

Accept : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

C=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 97 
m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
m=video 3004 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



51-55. SIP 200 (OK) response (from UE-3 to SCC AS-1 serving UE-1) 

The UE-3 sends a SIP 200 (OK) response with an SDP answer. 

Table A.1 1.5-51: SIP 200 (OK) response (UE-3 to SCC AS-1 serving UE-1) 



SIP/2.0 200 OK 
Via : 

To: sip : user3_publicl@home3 . net ; tag = 24861 
From: sip : interUEtransf er@home .net ; tag = 12486 
Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : <sip:user3 j>ublicl@home3 .net ;gr=urn:uuid: f81d4fae-7dec-lld0 -1111 -333333333333 > 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.67 
s=- 

c=123.23.45.67 

t = 

m=audio RTP/AVP 97 
m=video 13 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
m=video 1304 RTP/AVP 98 99 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



56-60. SIP ACK request (from SCC AS-1 serving UE-1 to UE-3) 

The SCC AS-1 serving UE-1 sends a SIP ACK request to the UE-3. 
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61-65. SIP NOTIFY request (from SCC AS-1 serving UE-1 to UE-2) 

The SCC AS-1 sends a SIP NOTIFY request including the SIP final response as a sipfrag body to UE-2 to 
inform about the success status of adding media to UE-3. 

Table A.11.5-61 : SIP NOTIFY request (SCC AS-1 serving UE-1 to UE-2) 



NOTIFY sip:user2 publicl@home2 . net ; gr=urn ;uuid: f 8 ld4fae-7dec -lldO- 1111 -222222222222 SIP/2.0 
Via: 

To : sip : user2_publicl@home2 . net ; tag=12 34 

From: sip : sip : interUEtransf erOsccasl . homel . net ; tag=3456 

Call-ID: 

CSeq: 

P- Asserted- Identity : 
Require : 

Contact : sip : interUEtransf erOsccasl . homel . net ; +g . 3gpp . iut- focus 

Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag; version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

Contact : <sip :user3_publicl@home3 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO - 1111- 3333 3 3 3 3 3 3 3 3 > 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.23.45.67 
s = - 

c=123 .23.45.67 
t = 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
m=video 1304 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



66-70. SIP 200 (OK) response (from UE-2 to SCC AS-1 serving UE-1) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS-1 serving 
UE-1. 



A.1 2 Signalling flows for session replication / media 
replication performed by the SCC AS 

A.1 2.1 Introduction 

The signalling flows for session replication/media replication performed by the SCC AS demonstrate how the session is 
replicated by the SCC AS. The following signalling flows are included: 

subclause A. 12.2 shows an example using the pull mode; and 

subclause A. 12.3 shows an example using the push mode. 
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A.12.2 Signalling flows for session replication / media replication 
performed by the SCC AS - pull mode 

In the example flow of figure A.12.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at the SCC AS. 
After successful replication, the media flow between UE-1 and UE-3 is not impacted. The replicated media 
component(s) are sent towards UE-2. UE-2 cannot send media flows towards UE-1 or UE-3 during this session. 
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HPLMN of the local UE participating In session and of the SCC AS replicating the 
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2. UE-2 decides to replicate 
tile session of UE-1. 
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Figure A.1 2.2-1 : Signalling flows for session replication by SCC AS from controller to another UE - 

pull mode 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between UE-1 and the remote UE-3 anchored 
at the SCC AS. 
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2. lJE-2 decides to replicate the session from UE-1 to UE-2. 

3. UE-2 fetches the dialog information of UE-1 from SCC AS. 

4-5. SIP EWITE request (UE-2 to UE-1) - see example in table A.12.2-4 

UE-2 sends a SIP INVITE request to UE-1 to perform the session replication. 

Table A.12.2-4: SIP INVITE request (UE-2 to Intermediate IM CN subsystem entities) 



INVITE sip: user l@example.net; SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7df dsdq 
Max- Forwards : 70 

P-Pref erred-Identity : <sip:user2@homel .net> 
From: <sip :user2®homel .net> ; tag=17182 8 
To: <sip:userltransf erOexample .net> 
Call-ID: Asdasd23123366 
Cseq: 41277 INVITE 

Contact : <sip:user2@homel .net ;gr=urn:uuid: f81d4fae- 7dec-lld0 -2222 -222222222222 > 
Accept -Contact : +g. 3gpp. iut- focus /explicit ; require 

Target -dialog: Cb03a0s09a2sdfglkj 11111 ; remote- tag=2 73 64 ; local-tag=1192 8 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa :bbb : ccc : eee 
s=- 

c=IN IP6 4444 :: aaa: bbb: ccc: eee 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=3gpp. iut . replication 



The SDP attribute "a= 3gpp.iut.repUcationindicates that the replication request is sent from the controUee UE and it 
uses the network based solution. 

6. SCC AS sends information to MRF to allocate the media resource for the media to be replicated. 

7-8. SIP 200 (OK) response for the SIP INVITE request (SCC AS to UE-2) 

The SCC AS responds with a SIP 200 (OK) response to UE-2. 
9-10. SIP ACK request (UE-2 to SCC AS) 

UE-2 sends a SIP ACK request to the SCC AS. 
11-12. SIP re-INVITE request (SCC-AS to UE-1) - see example in table A.12.2-11 

The SCC AS updates the access leg on Controller UE-1 for the replicated media flow with the MRF. 

Table A.1 2.2-1 1 : SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entities) 



INVITE sip : userl@homel .net ; SIP/2.0 

Via: SIP/2. 0/UDP 

Max-Forwards : 

P- Preferred- Identity : 

From: <sip : interUEtransf erOexample . net > ; tag=17182 8 

To: <sip :userl@homel . net> ; tag=297785 

Call-ID: 

Cseq: 41278 INVITE 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa :bbb : ccc : fff 
s=- 
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c=IN IP6 4444: :aaa:bbb:ccc:fff 
t=0 

m=audio 4444 RTP/AVP 97 
a= r tpmap : 9 7 PCMU/ 8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=3gpp. iut . replication 



13-14. SIP 200 (OK) response to re-INVITE request (UE-1 to SCC AS) - see example in table A.12.1-13 

After successful media update, UE-1 sends a SIP 200 (OK) reponse towards the SCC AS. 

Table A.12.3-13: SIP 200 (OK) response (UE-1 to Intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 
Via: 

Max- Forwards : 

P- Preferred- Identity : 

From: <sip : interUEtransf er@example .net> ; tag=17182 8 

To: <sip:userl@homel .net>; tag=297786 

Call-ID: 

Cseq: 

Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 : : aaa :bbb : ccc : f f f 
s=- 

c=IN IP6 4444: :aaa:bbb:ccc:fff 
t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=3gpp. iut . replication 



15-16. SIP ACK request (SCC AS to UE-1) 

The SCC AS sends a SIP ACK request to UE-1 . 

17-18. SIP re-INVITE request (SCC AS to UE-3) 

The SCC AS sends a SIP re-INVITE request towards the remote UE to update the remote leg to communicate 
media with the MRF. 

20-22. SEP 200 (OK) response to re-INVITE request (UE-3 to SCC AS) 

After successful media update, remote UE-3 sends a SIP 200 (OK) response towards the SCC AS. 
23-25. SIP ACK request (SCC AS to UE-3) 

The SCC AS sends a SIP ACK request to remote UE-3. 

A.12.3 Signalling flows for session replication / media replication 
performed by the SCC AS - push mode 

In the example flow of figure A. 12.3-1, UE-1 has an ongoing multimedia session with UE-3 anchored at the SCC AS. 
After successful replication, the media flow between UE-1 and UE-3 is not impacted. The replicated media 
component(s) are sent towards UE-2. UE-2 cannot send media flows towards UE-1 or UE-3 during this session. 
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Figure A.1 2.3-1 : Signalling flow for replicating media in network from controller to another UE- push 

mode 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between UE-1 and the remote UE-3 anchored 
at the SCC AS. 



2. UE-1 decides to replicate the session from UE-1 to UE-2. 
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3-4. SIP REFER request (UE-1 to SCC AS) - see example in table A.12.3-3 

UE-1 sends a SIP REFER request to the SCC AS to request the session replication. When the SCC AS receives 
the SIP REFER request, the SCC AS authorizes the request. 



Table A.12.3-3: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities) 



REFER sip : interUEtransf erOexample . net ; SIP/2.0 




Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ; branch= 


z9hG4bKnashds7dfdsdq 


Max- Forwards : 70 




P- Preferred- Identity : <sip : userlohomel . net > 




From : <sip : userlohomel . net > ; tag=17182 8 




To: <sip : user2@homel . net ; > 




Call-ID: Asdasd23123366 




Cseq: 41277 REFER 




Contact : <sip : userlohomel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO - 1111 - 


111111111111> 


Accept -Contact : +g . 3gpp . iut- focus s ; explicit ; require 




Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 




Refer- To : <sip : user30homel . net ?; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6?body= 


m%3Dvedio%2 9%2 0RTP%2FAVP%9B%0Dm% a=3gpp. iut . replication> 




Referred-by: sip : userlohomel . net 




Target -dialog: cb03a0s0 9a2sdf glkj 11111 ; remote -tag=2 73 64 ; local -tag= 


11928 


Content-Type: application/ 




Content-Length: (...) 





The SDP attribute "The SDP attribute "a= Sgpp.iut.replication" indicates that the replication request was sent from 
the controller UE and it uses the network based solution. 

5-6. SIP 202 (Accepted) response for the SIP REFER request (SCC AS to UE-1) 

7. SCC AS sends information to MRF to allocate the media resource for the media to be replicated. 

Editor's Note: There is a need to understand what functionality the MRF is providing. This can either be done by 

showing the instructions to the MRF or by showing the SDP in other messages thus enabling the activity 
of the MRF to be seen. 

8-9. SIP INVITE request (SCC AS to UE-2) - See example in table A.12.3-8 

The SCC AS sends a SIP INVITE request towards UE-2 to establish a session based on the information provided 
in the SIP REFER request. 

Table A.12.3-8: SIP INVITE request (SCC AS to UE-2) 



INVITE sip :user20homel . net ; gr=urn : uuid : f 8 ld4fae- 7dec- lldO -2222 -222222222222 SIP/2.0 
Via: SIP/2. 0/UDP 
Max-Forwards: 70 

From: <sip : userlohomel . net > ; tag=17182 8 

To: <sip:user20homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-2222-222222222222> 
Referred-By: sip: userlOexamplel.net 
Call-ID: duie4hr3896 
Cseq: 41 INVITE- 

Contact : <sip : userlohomel . net ; gr=urn : uuid : f 8 ld4fae-7dec- lldO- 1111 -111111111111 > 

Accept -Contact : +g . 3gpp . iut- focus ; explicit ; require 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Length: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa : bbb : ccc : eee 
s = - 

c=IN IP6 4444 :: aaa : bbb : ccc : eee 

t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=g . 3gpp . iut . replication 
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The sec AS adds the Referred-By header in order to indicate to UE-2 that this collaborative session request was 
triggered by UE-1. 

The SDP attribute "a= 3gpp.iut.rephcation" indicates that the replication request is sent by the SCC AS and it uses 
the network based solution. 

10-11. SIP 200 (OK) reponse to SIP INVITE request (UE-2 to SCC AS) 

UE-2 establishes the session by sending a SIP 200 (OK) response towards the SCC AS. 
12-13. SIP ACK request (SCC AS to UE-2) 

The SCC AS sends a SIP ACK request to UE-2. 
14-15. SIP re-EWITE request (SCC AS to UE-1) 

The SCC AS updates the access leg on Controller UE-1 for the replicated media flow with the MRF. 
16-17. SIP 200 (OK) response to re-INVITE request (UE-1 to SCC AS) 

After successful media update, UE-1 sends a SIP 200 (OK) reponse towards the SCC AS. 
18-19. SIP ACK request (SCC AS to UE-1) 

The SCC AS sends a SIP ACK request to UE-1. 
20-22. SIP re-EWITE request (SCC AS to UE-3) 

The SCC AS sends a SIP re-INVITE request towards the remote UE to update the remote leg to communicate 

media with the MRF. 

23-25. SIP 200 (OK) response to re-INVITE request (UE-3 to SCC AS) 

After successful media update, UE-3 sends a SIP 200 (OK) response towards the SCC AS. 
26-27. SIP ACK request (SCC AS to UE-3) 

The SCC AS sends a SIP ACK request to remote UE-3. 
29-30. SIP NOTIFY request (SCC AS to UE-1) 

The SCC AS informs UE-1 that the action triggered by the SIP REFER request was successfully completed. 
31-32. SIP 200 (OK) response to SIP NOTIFY request (UE-1 to SCC AS) 

UE-1 confirms the SIP NOTIFY request by sending a SIP 200 (OK) response to the SIP NOTIFY request. 

A.1 3 Signalling flows for session replication / media 
replication performed by the remote UE 

A.1 3.1 General 

The signalling flows in the subclause demonstrate how session rephcation / media replication performed by remote UE 
can be appUed on a session. 
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A.13.2 Signalling flows for session replication / media replication 
performed by the remote UE - pull mode 

A. 13.2.1 Introduction 

The signalling flows in the subclause demonstrate how pull mode session rephcation / media replication performed by 
remote UE can be apphed on a session. 

A. 13.2.2 Pull mode session replication 

In the example flow at the figure A. 13.2.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS- 
1. The session is established using an IMS communication service identified by ICSI um:um-7:3gpp- 
service.ims.icsi.iptv. UE-1 and UE-2 belong to different subscribers. UE-3 is an application server acting as a 
terminating UE. 
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Figure A.1 3.2.2-1 : Signalling flow for session replication in the remote UE - Pull mode 

NOTE 1: For clarity, the SIP 100 (Trying) messages and SIP NOTIFY with SIP 100 (Trying) are not shown in the 
signalUng flow. 

1. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS-1. The session was established using IMS communication service identified by ICSI 
urn:urn-7:3gpp-service.ims.icsi.iptv. The dialog identifier of the session between SCC AS-1 and UE-1 is 
AB03a0s09a2sdfglkj490333, remote-tag=dfg45, local-tag=444. 

2. UE-2 decides to replicate the session of UE-1 to UE-2, 

3. UE-2 fetches the dialog information of the UE-1 from SCC AS-1. 

4-9. SIP REFER request (UE-2 to UE-1) - see example in table A.13.2.2-4 
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The UE-2 sends SIP REFER request to UE-1 to request the playback state. When SCC AS-1 forwards the SIP 
REFER request, the SCC AS-1 authorizes the request. 

Table A.1 3.2.2-4: SIP REFER request 



REFER sip : userlohomel. net ;gr=urn:uuid:f81d4fae-7dec-lld0- 1111 -111111111111 SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max - Forwards : 7 

P- Preferred- Identity: <sip :user2®homel . net > 
From : <sip : user2@homel . net > ; tag=17182 8 

To : <sip : useriohomel . net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-llll-llllllllllll> 
Call-ID: ddf f tq34gasgaegr 
Cseq: 1112 REFER 

Contact : <sip:user2@homel . net ; gr=urn: uuid : f 8 ld4fae-7dec -lldO- 2222 -222222222222 > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content -Type : application/vnd. Sgpp . replication+xml 

Content-Length: (...) 

Supported: lOOrel, precondition 

Refer- To : <sip : user2@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lldO-2222- 
222222222222 ;method=MESSAGE?In-Reply-To=ddf f tq34gasgaegr> 
Target-Dialog: AB03a0s09a2sdfglkj 490333 ; remote-tag=df g45 ; local-tag=444 
Require: tdialog 

<?xml version="l . 0" encoding="UTF-8"?> 
<ms : requestedParameters 
xmlns :ms="urn: 3gpp:ns :mediaState : 1 . 0" 

> 

</ms : requestedParameters > 



Request-URI: set to the URI of UE-1 

Refer-To:contains the URI of UE-2 extended with the method parameter set to MESSAGE and with In-Reply- 
To URI header field containing the call-id of the SIP REFER request 

Target-Dialog: contains the dialog identifier of the session being replicated 

applicatioii/vnd.3gpp.replication+xinl: lists the playback state parameters to be provided 

NOTE 2: the playback state parameters are not shown 

10-15. SIP 202 (Accepted) response for the SIP REFER request (UE-1 to UE-2) 

16-21. SIP MESSAGE request (UE-1 to UE-2) 

Based on the received SIP REFER request, the UE-2 generate a SIP MESSAGE request with values of the 
requested playback state parameters. 

Table A.1 3.2.2-1 6: SIP MESSAGE request 



MESSAGE sip :user2@homel . net ; gr=urn : uuid : f 8 ld4fae-7dec- lldO- 2222 -222222222222 SIP/2 . 
Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : 32ff] : 887 ; comp=sigcomp ;branch=z9hG4bICnashds775 
Max-Forwards: 70 

P- Preferred- Identity : <sip : useriohomel . net > 
From : <sip : useriohomel . net > ; tag=aaal7182 8 

To : <sip : user20homel . net ;gr=urn:uuid: f81d4fae-7dec- lldO-2222 -222222222222 > 
Call-ID: df sgaerddf f tq34gasgaegr 
Cseq: 41112 MESSAGE 

Contact : <sip : useriohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lldO-llll-llllllllllll> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content -Type : application/vnd. 3gpp . replication+xml 

Content-Length: (...) 

Supported: lOOrel, precondition 

In-Reply-To: ddf f tq34gasgaegr 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<ms : parameterValues 
xmlns :ms="urn: 3gpp :ns :mediaState : 1 . 0" 

> 

</ms : parameterValues > 
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Request-URI: set to the URI of UE-2 

In-Reply-To: containing the value of the In-Reply-To URI header field of the Refer-To header field of the SIP 
REFER request 

application/vnd.Sgpp.replication+xml: lists the values of the requested playback state parameters 
NOTE 3: the playback state parameters and their values are not shown 
22-27. SIP 200 (OK) response to SIP MESSAGE request (UE-2 to UE-1) 

The UE-2 confirms the SIP MESSAGE request by sending SIP 200 (OK) response to SIP MESSAGE request. 
28-33. SIP NOTIFY request (UE-1 to UE-2) 

The UE-1 informs the UE-2 that the action triggered by SIP REFER request was successfully completed. 
34-39. SIP 200 (OK) response to SIP NOTIFY request (UE-2 to UE-1) 

The UE-2 confirms the SIP NOTIFY request by sending SIP 200 (OK) response to SIP NOTIFY request. 

40-44. SIP INVITE request (UE-2 to UE-3) 

The UE-2 establishes a session with UE-3 using the remote URI provided in the dialog event package in the step 
3. 

45-49. SIP 200 (OK) response to SIP INVITE request (UE-3 to UE-2) 

The UE-3 establishes the session by sending SIP 200 (OK) response to SIP INVITE request. 
50-54. SIP ACK request (UE-2 to UE-3) 

55. UE-2 sets up the playback state based on the playback state parameters received message 13. 
56-57. Media path: 

Two independent sessions exist - the original session still has the media path between UE-1 and UE-3 and the 
replicated session has the media path between UE-2 and UE-3. 

A. 13.3 Signalling flows for session replication / media replication 
performed by the remote UE - push mode 

A. 13.3.1 Introduction 

The signalling flows in the subclause demonstrate how push mode session replication / media replication performed by 
remote UE can be applied on a session. 

A. 13.3.2 Push mode session replication 

In the example flow at the figure A. 13.3.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS- 
1. UE-1 and UE-2 belong to different subscribers. 

Editor's Note (WID IMS_SC_eIDT): It is FES if the session replication can be replication of some of the media 
components belonging to the session. 
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HPLMN of the local UE participating in session and of the UE replicating the si 



HPLMNof the remote UE 
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14. 302 Accepted to REFER 
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I 5 
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38. NOTIFY 
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Figure A.1 3.3.2-1 : Signalling flow for replication of session existing at other UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses and SIP NOTIFY requests with SIP 100 (Trying) are not 
shown in the signalling flow. 

1. UE-l is in session with lJE-3 

The dialog identifier of the session between SCC AS-1 and UE-l is AB03a0s09a2sdfglkj490333, remote- 
tag=dfg45, local-tag=444. 

2. UE-l decides to replicate the session from UE-l to UE-2. 

3-9. SIP REFER request (UE-l to UE-2) - see example in table A.13.3.2-3 

The UE-l sends SIP REFER request to UE-2 to request the session replication. When SCC AS-2 receives the 
SIP REFER request, the SCC AS-2 authorizes the request. 
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Table A.1 3.3.2-3: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities) 



REFER sip :user2®homel . net ; gr=urn : uuid : f 8 ld4fae-7dec- lldO- 2222 -222222222222 SIP/2 . 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7df dsdq 
Max-Forwards: 70 

P- Preferred- Identity : <sip : useriohomel . net > 
From : <sip : useriohomel . net > ; tag=17182 8 

To : <sip :user2@homel .net ;gr=urn:uuid: f81d4fae-7dec- lldO-2222 -222222222222 > 
Call-ID: Asdasd23123366 
Cseq: 41277 REFER 

Contact : <sip : useriohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lldO-llll-llllllllllll> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Length: 

Refer- To : <sip : user3@home2 . net ?P- Preferred- Service=urn : urn- 7 : 3gpp- 

service . ims . icsi . ipt v&Accept- Contact =* %3b+g . 3gpp . icsi-ref %3d%22urn%253Aurn-7%253gpp- 
service . ims . icsi . iptv%22> 

Referred- By : <sip : userl@homel .net> 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; ealg=aes-cbc; spi-c=98765432 ; spi- 

s=87G54321; port-c=8642 ; port-s=7531 
Content-Type : application/vnd. 3gpp . replication+xml 
Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8"?> 

<ms : replication> 
<ms : parameterValues 

xmlns :ms="urn: 3gpp :ns :mediaState : 1 . 0" 
> 

</ms : parameterValues> 
</ms : replication> 



Request-URI: contains the GRUU of the UE-2 

Refer-To: contains the URI of UE-3 and IMS Communication Service of the existing session. 

applicatioii/vnd.3gpp.replication+xinl: indicates that push mode repUcation is requested and if available, lists 
the values of the playback state parameters 

NOTE 2: the playback state parameters and their values are not shown 

10-16. SIP 202 (Accepted) response for the SIP REFER request (UE-1 to UE-2) 

17-21. SIP INVITE request (UE-2 to UE-3) 

The UE-2 establishes a session with UE-3 based on the information provided in the SIP REFER request. 

Table A.1 3.3.2-1 7: SIP INVITE request (UE-2 to UE-3) 



INVITE sip:user3@home2 .net SIP/2.0 

Via: SIP/2 . 0/UDP 123. 112. 67. 87: 54 54; comp=sigcomp;branch=z9hG4bKnashds7df gdf sgr 

To: sip:user3@home2 .net 

From: sip :user2@homel .net ; tag=acegi 

Call-ID: Asdasd2312336asa6 

CSeq: 2 00 INVITE 

Max- Forwards : 70 

P-Pref erred-Identity : sip:user2@homel .net 

Contact : <sip:user2@homel .net ; gr=urn: uuid : f81d4fae- 7dec-lld0 -2222 -222222222222 >; +g . 3gpp . icsi- 
ref ="urn%3Aurn-7%3gpp-service . ims . icsi . iptv" 
P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . iptv 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- service . ims . icsi . iptv" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Supported: lOOrel, precondition, 199 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 

s=- 

t = 

m=audio 1456 RTP/AVP 96 
C=IN IP4 123.112.67.87 
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22-26. SIP 200 (OK) response to SIP INVITE request (UE-3 to UE-2) 

The UE-3 establishes the session by sending SIP 200 (OK) response to SIP INVITE request. 
27-31. SIP ACK request (UE-2 to UE-3) 
32-38. SIP NOTIFY request (UE-2 to UE-1) 

The UE-2 informs the UE-1 that the action triggered by SIP REFER request was successfully completed. 
39-45. SIP 200 (OK) response to SIP NOTIFY request (UE-1 to UE-2) 

The UE-1 confirms the SIP NOTIFY request by sending SIP 200 (OK) response to SIP NOTIFY request. 
46-47. Media 

Two independent sessions exist - the original session still has the media path between UE-1 and UE-3 and the 
replicated session has the media path between UE-2 and UE-3. 

A.1 4 Signalling flows for session discovery 
A.14.1 Introduction 

The signalling flows for discovery of sessions demonstrate how a UE can discover sessions of other subscriber. The 
following signalling flows are included: 

- subclause A. 14.2 shows an example when a UE discovers sessions of other subscriber of the same PLMN. 

- subclause A. 14.3 shows an example when a UE discovers sessions of other subscriber of the same PLMN 
including session descriptions. 

A.1 4.2 Discovery of sessions of another user of different IIVIS 
subscription 

In the example flow at the figure A. 14.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. 
UE-1 and UE-2 belong to different subscribers. 
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Figure A.1 4.2-1 : Discovery of sessions of user at other UE 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 

1-2. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS-1. The dialog identifier of the session between SCC AS-1 and UE-1 is 
AB03a0s09a2sdfglkj490333, remote-tag=dfg45, local-tag=444. 

3. UE-2 decides to discover sessions of user at UE-1 

4-7, SIP SUBSCRIBE request (from UE-2 to SCC AS-1) - see example in table A,14,2-4 

The UE-2 sends a SIP SUBSCRIBE request to fetch the dialog information of the dialogs of user at UE-1. SCC 
AS-2 is invoked upon originating initial filter criteria but since Request-URI does not contain a URI owned by 
SCC AS-2, the SCC AS-2 forwards the request. 
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Table A.1 4.2-4: SIP SUBSCRIBE request 



SUBSCRIBE sip: userlOhomel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7664 

P- Preferred- Identity : <sip : user2@homel . net> 

From : <sip : user2@homel . net > ; tag=17182 8 

To: <sip : userl@homel . net > 

Call-ID: tq34gasgaeg335r 

Event : dialog 

CSeq: 145454 SUBSCRIBE 

Max-Forwards: 70 

Expires : 

Contact : <sip : user2®homel . net ; gr=urn : uuid: f81d4fae- 7dec-lld0 -2222 -222222222222 > 
Accept : application/dialog- info+xml 

Accept -Contact : * ; +g . Sgpp . iut- focus ; explicit ; require 
Content-Length: 



8-11. SIP 202 (Accepted) response (from SCC AS-1 to UE-2) 

Since the request is addressed to a user served by SCC AS-1 and since the request contains the g.3gpp.iut-focus 
media feature tag in the Accept-Contact header field, the SCC AS-1 acknowledges the SIP SUBSCRIBE request 
by sending a SIP 202 (Accepted) response. 

12-15. SIP NOTIFY request (from SCC AS-1 to UE-2) - see example in table A.14.2-12 

The SCC AS-1 sends a SIP NOTIFY request containing the dialog information related to dialogs between the 
SCC AS-1 and the UEs of the subscribed user. 

Table A.14.2-12: SIP NOTIFY request 

NOTIFY sip :user2@homel .net ;gr=urn: uuid: f81d4fae-7dec- lldO -2222 -222222222222 SIP/2 . 

Via : 

To : <sip : user2®homel . net> ; tag=171828 
From : <sip :userl@homel . net > ; tag=eerr 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : sccasl . homel . example . net 
Allow: 

Event: dialog 

Content-Type : application/dialog-info+xml 
Content-Length: (...) 

<?xml version= " 1 . " ? > 

<dialog-info xmlns="urn: ietf :params :xml :ns :dialog-info" 

version= " " 
state="full" 

entity^ " sip : userlohomel . net " > 
<dialog id="123456" call- id= "AB03a0s09a2sdf glkj490333 " local-tag= "444 " remote- tag= "dfg45 " > 

< state >confirmed</ state > 
<local> 

<identity>sip : remoteuser@home2 . net</identity> 

< target uri= "sip : remoteuser@home2 . net ; gr=urn :uuid: f 81d4f ae -7dec-lld0-a765-333333333333"> 

<param pname= "+g . 3gpp . icsi-ref " pval="urn:urn-7 : 3gpp- service . ims . icsi . iptv"/> 

</target> 

</local> 

<remote> 

<identity>sip :userl®homel . net</identity> 

< target uri=" sip: userlohomel .net ; gr=urn: uuid: f81d4fae-7dec - lldO -a76 5 - 111111111111 " > 
<param pname= "+g . 3gpp .icsi-ref" pval="urn:urn-7 : 3gpp- service . ims . icsi . iptv"/> 
</target> 
</remote> 
</dialog> 
< /dialog- info 



16-19. SIP 200 (OK) response (from UE-2 to SCC AS-1) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC AS-1. 
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A. 14.3 Discovery of sessions of another user of different IIVIS 
subscription including session descriptions 

In the example flow at the figure A. 14. 3-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. 
UE-1 and UE-2 belong to different subscribers. 
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Figure A.14.3-1 : Discovery of sessions of user at otiier UE including session descriptions 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 

1-2. UE-1 is in session with UE-3 

There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS-1. The dialog identifier of the session between SCC AS-1 and UE-1 is 
AB03a0s09a2sdfglkj490333, remote-tag=dfg45, local-tag=444. 

3. UE-2 decides to discover sessions of user at UE-1 including session descriptions 

4-7. SIP SUBSCRIBE request (from UE-2 to SCC AS-1) - see example in table A.14.3-4 

The UE-2 sends a SIP SUBSCRIBE request to fetch the dialog information of the dialogs of user at UE-1. The 
UE-2 adds the "include-session-description" header field parameter to the Event header field. SCC AS-2 is 
invoked upon originating initial filter criteria but since Request-URI does not contain a URI owned by SCC AS- 
2, the SCC AS-2 forwards the request. 
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Table A.1 4.3-4: SIP SUBSCRIBE request 



SUBSCRIBE sip: userlOhomel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7664 
P- Preferred- Identity : <sip : user2®homel . net> 
From : <sip : user2@homel . net > ; tag=17182 8 
To: <sip : userl@homel . net > 
Call-ID: tq34gasgaeg335r 

Event: dialog; include-session-description 
CSeq: 145454 SUBSCRIBE 
Max-Forwards: 70 
Expires : 

Contact : <sip : user2®homel . net ; gr=urn : uuid: f81d4fae- 7dec-lld0 -2222 -222222222222 > 
Accept : application/dialog- info+xml 

Accept -Contact : * ; +g . Sgpp . iut- focus ; explicit ; require 
Content-Length: 



8-11. SIP 202 (Accepted) response (from SCC AS-1 to UE-2) 

Since the request is addressed to a user served by SCC AS-1 and since the request contains the g.3gpp.iut-focus 
media feature tag in the Accept-Contact header field, the SCC AS-1 acknowledges the SIP SUBSCRIBE request 
by sending a SIP 202 (Accepted) response. 

12-15. SIP NOTIFY request (from SCC AS-1 to UE-2) - see example in table A.14.3-12 

The SCC AS-1 sends a SIP NOTIFY request containing the dialog information related to dialogs between the 
SCC AS-1 and the UEs of the subscribed user. 
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Table A.14.3-12: SIP NOTIFY request 



NOTIFY sip :user2@homel .net ;gr=urn:uuid: f81d4fae-7dec- lldO -2222 -222222222222 SIP/2 . 
Via : 

To : <sip : user2®homel . net> ; tag=171828 
From : <sip : userlohomel . net > ; tag=eerr 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : sccasl . homel . example . net 
Allow: 

Event : dialog 

Content-Type : application/dialog-info+xml 
Content-Length: (...) 

<?xml version= " 1 . " ? > 

<dialog-inf o xmlns="urn: ietf :params :xml :ns :dialog-info" 

version^ " " 
state= " full " 

entity^ " sip : userlohomel . net " > 
<dialog id="123456" call- id= "AB03a0s09a2sdf glkj490333 " local-tag= "444 " remote- tag= "dfg45 " > 

< state >confirmed</ state > 
<local> 

<identity>sip : remoteuser@home2 . net</identity> 

< target uri = " sip : remoteuser@home2 . net ; gr=urn : uuid : f 8 ld4fae- 7dec- lldO -a76 5 -333333333333 " > 
<param pname= " +g . 3gpp . icsi-ref " pval= "urn : urn- 7 : 3gpp- service . ims . icsi . iptv" /> 

</target> 

<session-description type="application/sdp" > 
v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 
t = 

m=audio 49174 RTP/AVP 96 97 
C=IN IP4 132 . 54 . 76 . 98 

b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 1009 RTP/AVP 98 99 
c=IN IP4 132.54.76.98 
a=sendonly 
b=AS:75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

</session-description> 

</local> 

<remote> 

<identity>sip : userlohomel . net</identity> 

< target uri= " sip : userlohomel . net ;gr=urn:uuid: f81d4fae-7dec- Ild0-a765- 111111111111" > 
<param pname= "+g . 3gpp .icsi-ref " pval= "urn : urn- 7 : 3gpp- service . ims . icsi . iptv" /> 

</target> 

< session-description type= "application/ sdp"> 
v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 

s=- 
t=0 

m=audio 49174 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
b=AS : 2 5 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxpt ime : 2 

m=video 1009 RTP/AVP 98 99 
C=IN IP4 123.45.67.89 
a=sendonly 
b=AS:75 

a=rtpmap:98 H2 63 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

</session-description> 

</remote> 
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</dialog> 
< /dialog- info 



16-19. SIP 200 (OK) response (from UE-2 to SCC AS-1) 

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC AS-1. 



A.15 Signalling flows for collaborative session handling 
upon loss of collaborative session control 

A.15.1 Introduction 

The signalling flows in this subclause demonstrate how a control from controller UE-1 that is lost from the 
collaborative session can be transferred to UE-2. 

A. 15.2 Session hancJIing upon controller lost 



UE-1 



UE-2 



IMS CN 



SCC AS 



1. Collaborative session control 



- 5. INVITE 
6. 200 OK 



9. ACK 



.(Video-1). 



2. BYE with 503 
(Service Unavailable) 



3. Select candidate 
controller based on 
user preference 



4. INVITE 



7. 200 OK 



8. ACK 



10. Collaborative session control 
(Video-1) _ 



Remote 
UE 



1. Collaborative session controlled by UE-1 

A collaborative session is established between UE-1 and UE-2 and the remote UE with UE-1 acting as the 
controller UE and UE-2 acting as a controllee UE. For simplicity, other UEs participating in the session are not 
shown in this flow and only controllee UEs have media flows with the remote UE. 
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2. SIP BYE (EMS CN to sec AS) 

The S-CSCF receives a SIP BYE message with a reason header 503 (Service Unavailable) from P-CSCF that 
detecting the lost of UE, it routes this SIP BYE message to SCC AS of the session. 

3. SCC AS checks the controller loss preference user preference 

The SCC AS checks the controller loss preference user preference and selects a candidate UE as new controller. 

Otherwise the session is released. 

4. SIP re-INVITE request (SCC AS to intermediate EM CN subsystem entities) - see example in table A.15.2- 
4 

The SCC AS sends a SIP re-INVITE request towards the Controllee UE (UE-2). The re-INVITE request 
contains the XML body from the URI in the Refer-To header field from the SIP REFER request. 

Table A.I 5.2-4: SIP re-INVITE request (SCC-AS to IM CN subsystem entities) 



INVITE sip:user2_publicl@homel.net;gr=urn:uuid:f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 
Route : 

To : sip : user2_publicl@homel . net ; abcdef 
From: sip :user3_public3@home3 . net ; tag=1234 56 
Call-ID: 
CSeq: 

Max- Forwards : 
Require : 

Contact : sip :user3_public3@home3 .net ; gr=urn :uuid: f 81d4f ae-17oct-llal-a678-0054c91eabcd 

Allow: 

Accept : application/vnd . 3gpp . iut+xml 

Cont ent - Type : multipart/mixed; boundary= " boundary 1 " 

Content -Length: {...} 

- - boundary 1 

Content-Type: application/sdp 

v=0 

o=- 1027933615 1027933615 IN 132.54.76.98 
s = - 

c = IN IP4 132 . 54 . 76 . 98 

t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
b=AS:75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

- -boundaryl 

Cont ent -Type : application/vnd. 3gpp . iut+xml ; handling=optional 

<controlTransf er> 

< target Cont rol ler=<s ip :user2_public2@home2 .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a762 - 
00a0c91e6bf 6>/> 
</ControlTansf er> 
- -boundaryl 



5. SIP re-EWITE request (intermediate EM CN subsystem entities to UE-2) 

6-7. SIP 200 (OK) response (UE-2 to SCC AS through mtermediate EM CN subsystem entities) 

UE-2 accepts the transfer of control and indicates this by including a g.3gpp.current-iut-controller media feature 
tag set to Active in the SIP 200 (OK) response it sends to the SCC AS. 



ETSI 



3GPP TS 24.337 version 1 0.8.0 Release 1 239 ETSI TS 1 24 337 V1 0.8.0 (201 3-07) 

Table A.1 5.2-6: SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via : 

To : sip : userl_public2@homel . net ; tag=xyzwv 

From: sip : interUEtransf erOexample . net ; tag = 12486 

Call-ID: 

CSeq: 

P- Preferred- Identity : 

Contact : sip : user l_public2®homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 ; +g. 3gpp 

current - iut - control ler=Active 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 

s=- 

c=145.23.77.88 

t = 

m=audio RTP/AVP 97 
m=video 13 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



8-9. SIP ACK request (from SCC-AS to UE-2) 
10. Collaborative session controlled by UE-2 



A.1 6 Signalling flows for collaborative session media 
modification 

A.1 6.1 Introduction 

The signalling flow in this subclause demonstrate how a controUee UE initiated media modification on itself. 
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A.16.2 Controllee UE initiated media modification on itself 



UE-1 



UE-2 



sec AS-1 



sec AS-2 



Intermediate IM CN subsystem 
entities 



Remote Party 



-Collaborative Session Control- 



Media-A between U^-l and remote UE-3- 



-Media-B between UE-2 and remote UE-3- 



1. re-INVIT^ 



2. re-INVITE 



3. re-INVITE 



4. re-INVITE 



5. Authorization of request 



-Collaborative Session Control- 



6. re-INVITE 



9. 200 to re-INVITE 



10. 2001 OK to re-INVITE 



I 11. 200 OK to re-INVITE | 

K 1 

! 12. 200 OK to re-INVITE ! 



13. 200 OK to re-INVITE 



14. ACK 



15.ACK 



16. ACK 



1 17. ACK 



118. ACK 



Media-A between U^-1 and remote UE-3- 



7. re-INVITE 



8. 200 OK to re-INVITE 



19. ACK 



-Modified Media-B between UE-2 and remote UE-3- 



Figure 4.11.2.2-1: Controllee UE initiated media modification on itself 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1-4. SIP re-INVITE request (UE-2 to SCC AS-1) - see example in table 4.11.2.2-2 
The UE-2 sends SIP re-INVITE request to remote UE to modify the media on itself. 
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Table 4.11.2.2-1 : SIP re-INVITE request (UE-2 to Intermediate IM CN subsystem entities) 



INVITE sip : remoteuserohomel . net ; SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7df dsdq 
Max-Forwards: 70 

P- Preferred- Identity : <sip : user2@homel . net > 
From : <sip : user2@homel . net > ; tag=17182 8 
To : <sip : remoteuserohomel . net> ; tag=986765 
Call-ID: Asdasd23123366 
Cseq: 41277 INVITE 

Contact : <sip:user2@homel . net ; gr=urn : uuid : f 8 ld4fae-7dec- lldO- 2222 -222222222222 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa :bbb : ccc : eee 

s=- 

c=IN IP6 4444 :: aaa: bbb: ccc: eee 

t=0 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 



5. Authorizes the request for media modification. 

6-7. SIP re-INVITE request (SCC AS-1 to remote UE) 

After successful authorization, SCC AS-1 sends the SIP re-INVITE to the remote UE. 
8-13. SIP 200 (OK) response for the SIP re-INVITE request (Remote UE to UE-2) 

Remote UE responds with SIP 200 (OK) response to UE-2. 
14-19. SIP ACK request (UE-2 to remote UE) 

The UE-2 sends the SIP ACK request to remote UE. 
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Annex B (normative): 

Media feature tags and feature-capability indicators defined 
witiiln tine current document 



B.1 General 

This subclause describes the media feature tag definitions and the feature-capability indicator definitions that are 
appUcable for the 3GPP IM CN Subsystem for the realisation of the lUT transfer controller functions. 



B.2 Definition of media feature tag g.Sgpp.iut-controller 

Media feature-tag name: g.Sgpp.iut-controller 
ASN.l Identifier: 1.3.6.1.8.2.9 

Summary of the media feature indicated by this tag: This media feature-tag when used in a SIP request or a SIP 
response indicates that the function sending the SIP message supports the lUT Controller functionaUty.This media 
feature tag does not imply that the controller UE capabilities are handled in the same protocol manner. 

Values appropriate for use with this feature-tag: Boolean 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications appUcation, for describing the capabilities of a device, 

such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the lUT controller capability 

Related standards or documents: 3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 14.1 of 
IETF RFC 3840 [24]. 



B.3 Definition of media feature tag g.3gpp.iut-focus 

Media feature-tag name: g.3gpp.iut-focus 
ASN.l Identifier: 1.3.6.1.8.2.10 

Summary of the media feature indicated by this tag: 

This media feature-tag when used in a Contact header field or a Accept-Contact header field of a SIP request or a SIP 
response indicates that the function sending the SIP message supports anchoring a lUT session and/or the SIP message 
is an inter-UE transfer operation. 

Values appropriate for use with this feature-tag: Boolean 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 

mechanisms: This feature-tag is most useful in a communications application, for indicating that the function sending 
the SIP message supports anchoring a lUT session and/or the SIP message request is an inter-UE transfer operation. 

Examples of typical use: Indicating that a SCC AS has anchored the related lUT session and/or indicating that to the 
IMS core that the SIP message is an inter-UE transfer operation. 

Related standards or documents: 3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3" 
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Security Considerations: Security considerations for this media feature-tag are discussed in subclause 14.1 of 
IETF RFC 3840 [34]. 

B.4 Definition of media feature tag g.3gpp.current-iut- 
controller 

Media feature-tag name: g.3gpp.current-iut-controller 

ASN.l Identifier: 1.3.6.1.8.2.11 

Summary of the media feature indicated by this tag: 

This media feature-tag when used in a Contact header field of SIP request or SIP response indicates that the UA is the 
currently active lUT controller for the collaborative session or is a controllee in the collaborative. The values of the 
feature tag are "active" and "passive". 

Values appropriate for use with this feature-tag: string with syntax as follows: 

"active" indicates that the UA is the currently active lUT controller for the collaborative session. 

"passive" indicates that the UA is a controllee in the collaborative session but is willing to become an active controller 
for the collaborative session. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for Inter UE control transfer operation. 

Examples of typical use: Indicating that a UA wishes to relinquish control of the collaborative session and requesting a 
UA to become the active lUT controller for the collaborative session. 

Related standards or documents: 3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 14.1 of 
IETF RFC 3840 [24]. 

B.5 Definition of feature-capability indicator g.Sgpp.iut- 
focus 

Feature-capability indicator name: 
g.3gpp.iut-focus 

Summary of feature indicated by this feature-capabiUty indicator: 

This feature -capability indicator when used in a Feature-Caps header field of a SIP request or a SIP response indicates 
that the function which inserted the Feature-Caps header field supports anchoring an lUT session. 

Feature-capability indicator specification reference: 

3GPP TS 24.337, http://www.3gpp.org/ftp/Specs/archive/24_series/24.337/ 

Values appropriate for use with this feature-capability indicator: 

none 

Examples of typical use: 

Indicating that a SCC AS has anchored the related lUT session. Examples can be found in 3GPP TS 24.337: "IP 
Multimedia Subsystem (IMS) inter-UE transfer; Stage 3". 

Security considerations: Security considerations for this feature-capability indicator are discussed in clause 9 of 
IETF RFC 6809 [44]. 
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Annex C (informative): 
XIVIL schemas 

C.1 Replication body 



C.1.1 General 

This subclause defines XML schema and MIME type of the replication body. 

NOTE: IMS communication services using the session replication can define parameters describing the playback 
state parameters by substitution of the parameterAbstract element. 



C.1.2 XML schema 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 
<xs : schema 

targetNamespace= "urn : 3gpp : ns : replication : 1 . " 
xmlns :xs="http : //www.w3 . org/2 1/XMLSchema" 
xmlns :ms= "urn : 3gpp : ns : replication : 1 . " 
elementFormDef ault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs : element name= " request edParameters " type= "ms : requestedParametersType" / > 
<xs : complexType name=" requestedParametersType" > 
<xs : sequence> 

<xs:element ref="ms : parameterAbstract" minOccurs= " " maxOccurs= "unbounded" /> 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 

</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

<xs : element name= "parameterValues " type= "ms : parameterValuesType" / > 
<xs : complexType name="parameterValuesType" > 
<xs : sequence> 

<xs:element ref= "ms : parameterAbstract " minOccurs= " " maxOccurs= "unbounded" / > 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 

</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

<xs:element name= "parameterAbstract " type="ms iparameterAbstractType" abstract= " true" / > 
<xs : complexType name= "parameterAbstractType" / > 

<xs:element name= " replication" type= "ms : replicationType" /> 
<xs : complexType name= "replicationType" > 
<xs : sequence> 

<xs: element ref= "ms : parameterValues " minOccurs= " " / > 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

</xs : schema> 

C.1 .3 lANA registration template 

Editor"s note (WID IMS_SC_eIDT): The MIME type "application/vnd.3gpp.replication+xml" as defined in this 

subclause is to be registered in the lANA registry for Application Media Types based upon the following 
template when the Rel-10 is frozen. 

MIME media type name: 

application 

MIME subtype name: 



ETSI 



3GPP TS 24.337 version 1 0.8.0 Release 1 245 ETSI TS 1 24 337 V1 0.8.0 (201 3-07) 

vnd . 3 gpp . replic ation+xml 
Required parameters: 
None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [29]. 

Encoding considerations: 

binary 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [29]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [30] apply. 

The information transported in this MIME media type does not include active or executable content. 

Mechanisms for privacy and integrity protection of protocol parameters exist. Those mechanisms as well as 
authentication and further security mechanisms are described in 3GPP TS 24.229 [7]. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [29]. 

The requestedParameters element is the root element, when the body contains the playback state parameters to be 
provided. The parameterValues element is the root element, when the body contains the playback state parameter 
values. The replication element is the root element, when the body indicates replication request. 

Published specification: 

3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3", available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the inter-UE transfer as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 

Editor's note (WID IMS_SC_eIDT): it is EES whether to have a separate MIME type for playback state. 



C.2 lUT transfer feature XML schema 
C.2.1 General 

This subclause defines XML schema and MIME type related to the lUT transfer features. 
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<?xml version= " 1 . " encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs="http : //www . w3 . org/2 001/XMLSchema" 
element FormDefault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs:element name= " controlTransf er " type= "TcontrolTransf er " / > 

<xs : complexType name="TcontrolTransf er" > 
<xs : sequence> 

<xs:element name="controllee" type= "xs : anyURI " minOccurs= " " maxOccurs= "unbounded" / > 
<xs:element name= " targetController " type= "xs : anyURI " minOccurs= " " maxOccurs="unbounded"/> 
<xs: element name= " activeController " type= "xs : anyURI " minOccurs= " " maxOccurs= "unbounded" / > 
<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

</xs : schema> 

C.2.3 lANA registration template 

Editor"s note: The MIME type "application/vnd.3gpp.iut+xml" as defined in this subclause is to be registered in the 
lANA registry for AppUcation Media Types based upon the following template. 

MIME media type name: 

apphcation 

MIME subtype name: 

application/vnd . 3 gpp . iut+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [29]. 

Encoding considerations: 

binary. 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [29]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [30] apply. 

The information transported in this MIME media type does not include active or executable content. 

Mechanisms for privacy and integrity protection of protocol parameters exist. Those mechanisms as well as 
authentication and further security mechanisms are described in 3GPP TS 24.229 [7]. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [29]. 
Published specification: 

3GPP TS 24.337: 'TP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3", available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 
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Applications supporting the Inter UE Transfer as described in the pubhshed specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 

C.3 lUT preferences XML schema 

C.3.1 General 

This subclause defines XML schema and MIME type related to lUT user preferences. 

The lUT service contains a rule set that specifies how the TUT service shall react to external stimuli. 

The AUID of the lUT user preferences XCAP application usage is "org.3gpp.iut". 

The default namespace of the lUT user preferences XCAP application usage is "urn:3gpp:ns:iut: 1.0". 

The MIME type of the lUT user preferences XML document is specified in annex C.4. 

C.3. 2 Structure of the XML document 
0.3.2.1 lUT element 

The lUTconfiguration can contain a Controller Loss Preferences element and a rule set. 

The rule set reuses the syntax as specified by the common policy draft (see IETF RFC 4745 [42]). 

<iut active= " true " > 
<cp:ruleset> 

rulel 
rule2 

</cp : ruleset> 
</ iut> 

In general the following procedure appUes: 

When the service processes a set of rules it shall start with the first rule and test if its conditions are all true, if this is the 
case the rule matches and the specified action shall be executed. 

When the rule does not match the following rule shall be selected and the same procedure repeated, until a matching 
rule is found or the set of remaining rules is empty. 

In subclause C.3. 2.4 all allowed conditions are specified, normally rules are evaluated at communication setup time, for 
conditions where this is not the case this is explicitly indicated. 

0.3.2.2 lUT rules 

The lUT service is configured with an ordered set of lUT rules. The XML Schema reuses the rule syntax as specified by 
the common policy draft (see IETF RFC 4745 L42J). The rules take the following form: 

<cp:rule id=" rule66" > 
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<cp:conditions> 

conditionl 

condition2 
< / cp : condi t ions > 
<cp:actions> 

<enable- col laborative-sess ions /> 
</cp: act ions > 
</cp:rule> 



To give more guidance, examples of rules are shown below: 

<cp:rule id=" rule66" > 
<cp : conditions> 

<media>PCMA</media> 

<cp : identity> 

<cp : one>id=serveduser@domain</cp : one> 

</cp : identity> 
</cp : conditions> 
<cp : actions> 

< enable -col laborative-sess ions/ > 
</cp : actions> 
</cp:rule> 



<cp:rule id=" rule66" > 

< cp : condi t ions / > 

<cp:actions> 
<cont roller- loss -preferences> 
<controller>uri</controller> 
< /controller- loss -preference> 

</cp: act ions > 

</cp:rule> 



When the service processes a set of rules it shall start with the first rule and test if its conditions are all true, if this is the 
case the rule matches and the specified action is executed. When a rule matches remaining rules in the rule set shall be 
discarded. AppUed to the fragment above this means that only if the expression {conditionl AND condition2) evaluates 
to true that then the rule66 matches and the forward-to action is executed. 

When the rule does not match the following rule shall be selected and the same procedure repeated, until a matching 
rule is found or the set of remaining rules is empty. 

The "id" attribute value of a rule shall uniquely identify the rule within a rule set. This can be used in XCAP usage to 
address one specific rule. 

C.3.2.3 lUT rule conditions 

The following conditions are allowed by the XML Schema for lUT service: 

- cp:identity: This condition evaluates to true when the calling user's identity matches with the value of the 
identity element. The interpretation of all the elements of this condition is described in OMA-TS-XDM-Core- 
Vl_l [45]. In all other cases the condition evaluates to false. The Identity shall be matched against the value 
taken from the P-Asserted-Identity header field, and in addition as an option matched against the From header 
field and/or the Referred-By header field, unless both the <identity> element value and the Contact header field 
value contain a "gr" parameter, then the <identity> element value shall be matched against the value taken from 
the Contact header field; 

- anonymous: This condition evaluates to true when the P-Asserted-Identity of the calling user is not provided or 
privacy restricted; 

- media: When the incoming call request for certain media, the forwarding rule can decide to forward the call for 
this specific media. This condition evaluates to true when the value of this condition matches the media field in 
one of the "m=" lines in the SDP (IETF RFC 4566 [41]) offered in an INVITE request (IETF RFC 3261 [26]). 

NOTE: As described in IETF RFC 4745 [42] the case of unconditional evaluates to be true in all cases where all 
other reasons are not apphcable. Collaborative sessions are enabled as soon as the served user is the 
called user. The indication of unconditional is the absence of any reason element in the cp:conditions 
element. 
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The following conditions are allowed by the XML Schema for the lUT service: 

- ICSI: This condition evaluates to true when the value of the ICSI element matches with a URI parameter in the 
P-Asserted-Service header field; 

- RequestURI: This condition evaluates to true when the value of the RequestURI element matches with the 
Request-URI. 

Information of which of the above mentioned conditions the user is allowed to use can be obtained from the network by 
using the schema defined in subclause C.3.3. 

C.3.2.4 lUT rule actions 

The action supported by the CDIV service is forwarding of calls. For this the forward-to action has been defined. The 
forward-to action takes the following elements: 

enable-coUaborative-sessions: specifies that collaborative sessions are enabled. 

controller-loss-preferences: candidate UEs in controller loss preferences can be configured using the value of the 
<controller> child element of the <controller-loss-preferences> element. Each <controller> element contains a URI. 
The URI identifies a UE that is a candidate UE for controller loss preference in priority order. 

C.3.3 XML schema 

<?xml version="l . 0" encoding= "UTF-8 " ? > 

<xs : schema xmlns :xs= "http : / /www. w3 . org/2 01/XMLSchema" 
xmlns : iut= "urn : 3gpp : ns : iut : 1 . " 

xmlns : cp= "urn : ietf : params ;xml :ns : common -policy" 
xmlns : ocp= "urn : oma : xml : xdm : common-policy" 
targetNamespace= " urn : 3gpp : ns : iut : 1 . " 
elementFormDef ault= " qualified" 
attributeFormDef ault= "unqualified" > 
<!-- import common policy definitions --> 

<xs : import namespace= "urn : ietf : params :xml :ns : common -policy" schemaLocation= "common-policy . xsd" /> 
<!-- import OMA common policy extensions --> 

<xs : import namespace= "urn : oma : xml : xdm: common-policy" schemaLocation= "OMA-SUP-XSD_xdm_commonPolicy- 
Vl_0_2-2 0070830-A.xsd"/> 
<!-- IUT specific extensions to IETF common policy conditions --> 
<!-- IUT rule set based on the common policy rule set.--> 
<xs: element name="iut"> 
<xs : annotation> 

<xs : documentation>This is the IUT configuration document . </xs : documentation> 
</xs : annotation> 
<xs : complexType> 

<xs : sequence> 

<xs: element ref = " cp : ruleset " minOccurs= " " / > 
< /xs : sequence> 

<xs : attribute name="active" type= "xs : boolean" use="optional" def ault= " true" /> 

<xs : anyAttribute namespace="##any" processContents= " lax" /> 
</xs : complexType> 
</xs :element> 

<!-- iut specific to extensions IETF common policy conditions --> 
<xs:element name=" anonymous" type= " iut : empty-element- type" / > 
<xs:element name= "RequestURI " type= "xs : anyURI " /> 
<xs:element name="ICSI" type= "xs : string" /> 
<xs : complexType name="supported-media-type"> 
<xs : choice> 

<xs:element name="all-media" type= " iut : empty-element- type "/ > 

<xs:element name="no-media" type= " iut : empty-element- type" / > 

<xs : sequence maxOccurs="unbounded" > 

<xs:element name="media" type= " iut : media- type "/ > 

</xs : sequence> 

<xs : any namespace= " ##other " processContents= " lax" /> 
</xs : choice> 
</xs : complexType> 

<!-- iut specific extensions to IETF common policy actions--> 

<xs : element name= "enable -collaborative- sessions " type= " iut : empty-element- type" /> 
<xs : element name="controller-loss-preferences"> 

<xs : complexType > 
<xs : sequence> 

<xs:element name=" controller" type= "xs : anyURI " minOccurs= " " maxOccurs= "unbounded" /> 
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</xs : sequence> 
</xs : complexType> 
</xs : element > 

<!-- utility xml elements --> 

<xs : complexType name= " empty- element -type" / > 

<xs : simpleType name="media-type" final="list restriction" > 

<xs : restriction base= "xs : string" / > 

</xs : simpleType> 

</xs : schema> 

C.3.4 lANA registration template 

Editor's note: The MIME type "application/vnC.3gpp.iut-config+xml" as defined in this subclause is to be registered 
in the lANA registry for Application Media Types based upon the following template. 

MIME media type name: 

Application. 

MIME subtype name: 

vnC.3gpp.iut-config+xml. 

Required parameters: 

None. 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [29]. 

Encoding considerations: 

binary. 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [29]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [30] apply. Furthermore, 3GPP has defined mechanisms for ensuring the privacy and integrity 
protection of the bodies of XCAP messages used in the 3GPP IM CN Subsystem. 

The information transported in this MIME media type does not include active or executable content. 

Mechanisms for privacy and integrity protection of protocol parameters exist. Those mechanisms as well as 
authentication and further security mechanisms are described in 3GPP TS 24.229 [7]. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [29]. 
Published specification: 

3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3" 
Applications which use this media: 

Applications that use the 3GPP IM CN Subsystem as defined by 3GPP. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 
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2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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Annex D (normative): 

SDP Attributes defined within the current document 
D.1 General 

This subclause describes the SDP attribute definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of the lUT functions. 



D.2 Definition of SDP attribute a=3gpp.iut.replication 

SDP Attribute name: a=3gpp.iut.replication 

Summary of the SDP attribute indicated by this attribute: This SDP attribute when used in a SIP request or a SIP 
response indicates how the session/media replication is performed. 

Values appropriate for use with this feature-tag: none 

The 3gpp.iut.replication attribute is both a session-level attribute and media-level attribute, and it is not dependent on 
the charset. 

Examples of typical use: Indicating that the media/session is to be replicated. . 

Related standards or documents: 3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3" 
Security Considerations: none 

D.3 Definition of SDP attribute a=3gpp.iut.controllee 

SDP Attribute name: a=3gpp.iut.controllee 
ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Editor's note: The lANA registration needs to be done when Rel-10 frozen. 

Summary of the SDP attribute indicated by this attribute: This SDP attribute when used in a SIP request or a SIP 
response indicates the SIP address of the controllee UE in collaborative session. 

Values appropriate for use with this attribute: 

<address> = SIP address of controllee UE 

The 3gpp.iut.controllee attribute is a media attribute and it is not dependent on charset. 

Examples of typical use: Indicating that the media is established in the controllee UE of the collaborative session. 
Related standards or documents: 3GPP TS 24.337: "IP Multimedia Subsystem (IMS) inter-UE transfer; Stage 3" 
Security Considerations: none 
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